Re: [Django] #15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3

[Django]

#15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 
MySQL
Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3
-+-
 Reporter:  david_heagney|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  syncdb mysql |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 http://how-study-abroad.com

-- 
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] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
--+
 Reporter:  jakub |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  contrib.contenttypes  |  Version:  1.3
 Severity:  Normal|   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 julien):

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


Comment:

 This ticket is actually different than #16803 as it suggests including the
 app's name in the unicode representation. This is useful for when models
 from different apps have the same 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] #17897: Link https://www.djangoproject.com/weblog/2012/ma/ does not work

[Django]

#17897: Link https://www.djangoproject.com/weblog/2012/ma/ does not work
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by russellm):

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


Comment:

 This is @hackernewsbot's problem, not Django's. The original tweet from
 @ubernostrum contained the correct URL. @hackernewsbot has copied that
 tweet incorrectly.

-- 
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] #17897: Link https://www.djangoproject.com/weblog/2012/ma/ does not work

[Django]

#17897: Link https://www.djangoproject.com/weblog/2012/ma/ does not work
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 @hackernewsbot: Django's future, and Python 3...
 https://www.djangoproject.com/weblog/2012/ma/ does not work was a link
 that was found from the twitter user @hackernewsbot.

-- 
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] #13338: adding custom template context processor(s) to settings.py screws up admin

[Django]

#13338: adding custom template context processor(s) to settings.py screws up 
admin
-+-
 Reporter:  marshall.ent@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Template system  |  Version:  1.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  template context | Triage Stage:
  processor  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 http://how-study-abroad.com

-- 
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] #17896: Implement file hash computation as a separate method of staticfiles' CachedFilesMixin

[Django]

#17896: Implement file hash computation as a separate method of staticfiles'
CachedFilesMixin
-+-
 Reporter:  mkai |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  SVN
Component:  contrib.staticfiles  |   Keywords:
 Severity:  Normal   |  CachedStaticFilesStorage, hash, md5
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 I'm currently extending django-cumulus (Rackspace Cloud Files storage
 backend) and S3BotoStorage (Amazon S3 storage backend) to use hashed file
 names using the CachedFilesMixin of contrib.staticfiles. That came down to
 (as intended, I suppose!):

 {{{
 class MyCachedCloudFilesStorage(CachedFilesMixin, CloudFilesStorage):
 pass

 }}}

 Now I noticed that both Amazon and Rackspace include file hashes for each
 file in their API responses. It the response (e. g. a file list) is cached
 appropriately, the post-processing of the CachedFilesMixin can be sped up
 dramatically by just getting the hash from the cached response instead of
 calculating it from the file (which is expensive because it reads the file
 over the network).

 I propose the attached patch so that backend authors can implement their
 own method of getting the hash for a file:

 {{{
 diff --git a/django/contrib/staticfiles/storage.py
 b/django/contrib/staticfiles/storage.py
 index c000f97..e59b987 100644
 --- a/django/contrib/staticfiles/storage.py
 +++ b/django/contrib/staticfiles/storage.py
 @@ -65,6 +65,13 @@ class CachedFilesMixin(object):
  compiled = re.compile(pattern)
  self._patterns.setdefault(extension, []).append(compiled)

 +def get_file_hash(self, name, content=None):
 +"""Gets the MD5 hash of the file."""
 +md5 = hashlib.md5()
 +for chunk in content.chunks():
 +md5.update(chunk)
 +return md5.hexdigest()[:12]
 +
  def hashed_name(self, name, content=None):
  parsed_name = urlsplit(unquote(name))
  clean_name = parsed_name.path.strip()
 @@ -79,13 +86,9 @@ class CachedFilesMixin(object):
  return name
  path, filename = os.path.split(clean_name)
  root, ext = os.path.splitext(filename)
 -# Get the MD5 hash of the file
 -md5 = hashlib.md5()
 -for chunk in content.chunks():
 -md5.update(chunk)
 -md5sum = md5.hexdigest()[:12]
 +file_hash = self.get_file_hash(clean_name, content)
  hashed_name = os.path.join(path, u"%s.%s%s" %
 -   (root, md5sum, ext))
 +   (root, file_hash, ext))
 }}}

-- 
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] #23: Add support for ValidationWarning

[Django]

#23: Add support for ValidationWarning
-+
 Reporter:  adrian   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by anonymous):

 http://how-study-abroad.com

-- 
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] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
--+
 Reporter:  jakub |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.contenttypes  |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 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 ramiro):

 * stage:  Fixed on a branch => 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] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
-+-
 Reporter:  jakub|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:   |   Resolution:  fixed
  contrib.contenttypes   | Triage Stage:  Fixed on
 Severity:  Normal   |  a branch
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Fandekasp):

 * status:  new => closed
 * cc: lemaire.adrien@… (added)
 * resolution:   => fixed
 * stage:  Accepted => Fixed on a branch


Comment:

 Contenttype.__unicode__() has been modified with #16803.

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

[Django]

#17838: prefetch_related fails for GenericForeignKeys when related object id is 
not
a CharField/TextField
-+-
 Reporter:  mkai |Owner:  anonymous
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  SVN
  contrib.contenttypes   |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  prefetch_related |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Przemek Lewandowski ):

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


-- 
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] #17663: Method "save" in BaseModelFormSet is not marked as alters_data

[Django]

#17663: Method "save" in BaseModelFormSet is not marked as alters_data
-+-
 Reporter:  aiv  |Owner:  Fandekasp
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * cc: lemaire.adrien@… (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] #17663: Method "save" in BaseModelFormSet is not marked as alters_data

[Django]

#17663: Method "save" in BaseModelFormSet is not marked as alters_data
-+-
 Reporter:  aiv  |Owner:  Fandekasp
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * owner:  nobody => Fandekasp


Comment:

 This patch is not good, no path is given to the models.py. Notice 222
 models.py exist in the project
 (find . -name "models.py"|wc). Anyways, I found it after a grep, will now
 write the test.

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

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

Re: [Django] #17683: `BaseModelFormSet` ignore form's widgets options when adding the pk field

[Django]

#17683: `BaseModelFormSet` ignore form's widgets options when adding the pk 
field
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  basemodelformset | Triage Stage:  Ready for
  widget |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * stage:  Accepted => Ready for checkin


Comment:

 Good

-- 
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] #17714: Markdown filter does not support multiple configuration options for extensions

[Django]

#17714: Markdown filter does not support multiple configuration options for
extensions
-+-
 Reporter:  scottie_000  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.markup   |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  markup, markdown | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Fandekasp):

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


Comment:

 Looks good to me

-- 
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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by carbonXT):

 * cc: mike@… (added)


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

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

[Changeset] r17709 - in django/trunk/django: db/backends db/backends/postgresql_psycopg2 test

[noreply]

Author: aaugustin
Date: 2012-03-13 16:29:15 -0700 (Tue, 13 Mar 2012)
New Revision: 17709

Modified:
   django/trunk/django/db/backends/__init__.py
   django/trunk/django/db/backends/postgresql_psycopg2/base.py
   django/trunk/django/db/backends/postgresql_psycopg2/operations.py
   django/trunk/django/test/signals.py
Log:
Fixed #17882 (again) -- Updated the database connections' time zone when 
time-zone-related settings are changed in tests.


Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2012-03-13 23:02:31 UTC (rev 
17708)
+++ django/trunk/django/db/backends/__init__.py 2012-03-13 23:29:15 UTC (rev 
17709)
@@ -710,6 +710,14 @@
 """
 raise NotImplementedError
 
+def set_time_zone_sql(self):
+"""
+Returns the SQL that will set the connection's time zone.
+
+Returns '' if the backend doesn't support time zones.
+"""
+return ''
+
 def sql_flush(self, style, tables, sequences):
 """
 Returns a list of SQL statements required to remove all data from

Modified: django/trunk/django/db/backends/postgresql_psycopg2/base.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/base.py 2012-03-13 
23:02:31 UTC (rev 17708)
+++ django/trunk/django/db/backends/postgresql_psycopg2/base.py 2012-03-13 
23:29:15 UTC (rev 17709)
@@ -190,7 +190,8 @@
 # Set the time zone in autocommit mode (see #17062)
 self.connection.set_isolation_level(
 psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)
-self.connection.cursor().execute("SET TIME ZONE %s", [tz])
+self.connection.cursor().execute(
+self.ops.set_time_zone_sql(), [tz])
 self.connection.set_isolation_level(self.isolation_level)
 self._get_pg_version()
 connection_created.send(sender=self.__class__, connection=self)

Modified: django/trunk/django/db/backends/postgresql_psycopg2/operations.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/operations.py   
2012-03-13 23:02:31 UTC (rev 17708)
+++ django/trunk/django/db/backends/postgresql_psycopg2/operations.py   
2012-03-13 23:29:15 UTC (rev 17709)
@@ -71,6 +71,9 @@
 return name # Quoting once is enough.
 return '"%s"' % name
 
+def set_time_zone_sql(self):
+return "SET TIME ZONE %s"
+
 def sql_flush(self, style, tables, sequences):
 if tables:
 # Perform a single SQL 'TRUNCATE x, y, z...;' statement.  It allows

Modified: django/trunk/django/test/signals.py
===
--- django/trunk/django/test/signals.py 2012-03-13 23:02:31 UTC (rev 17708)
+++ django/trunk/django/test/signals.py 2012-03-13 23:29:15 UTC (rev 17709)
@@ -1,14 +1,23 @@
 from django.conf import settings
-from django.db import close_connection
+from django.db import connections
 from django.dispatch import Signal
 
 template_rendered = Signal(providing_args=["template", "context"])
 
 setting_changed = Signal(providing_args=["setting", "value"])
 
-# Close the database connection to re-establish it with the proper time zone.
-def close_connection_on_time_zone_change(**kwargs):
-if (kwargs['setting'] == 'USE_TZ'
-or (kwargs['setting'] == 'TIME_ZONE' and not settings.USE_TZ)):
-close_connection()
-setting_changed.connect(close_connection_on_time_zone_change)
+def update_connections_time_zone(**kwargs):
+if kwargs['setting'] == 'USE_TZ' and settings.TIME_ZONE != 'UTC':
+USE_TZ, TIME_ZONE = kwargs['value'], settings.TIME_ZONE
+elif kwargs['setting'] == 'TIME_ZONE' and not settings.USE_TZ:
+USE_TZ, TIME_ZONE = settings.USE_TZ, kwargs['value']
+else:   # no need to change the database connnections' time zones
+return
+
+tz = 'UTC' if USE_TZ else TIME_ZONE
+for conn in connections.all():
+tz_sql = conn.ops.set_time_zone_sql()
+if tz_sql:
+conn.cursor().execute(tz_sql, [tz])
+
+setting_changed.connect(update_connections_time_zone)

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | 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 aaugustin):

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


Comment:

 In [17709]:
 {{{
 #!CommitTicketReference repository="" revision="17709"
 Fixed #17882 (again) -- Updated the database connections' time zone when
 time-zone-related settings are changed in tests.
 }}}

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

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

Re: [Django] #17895: override_settings doesn't send the setting_changed signal when restoring the original value

[Django]

#17895: override_settings doesn't send the setting_changed signal when restoring
the original value
---+
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  SVN
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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


Comment:

 In [17708]:
 {{{
 #!CommitTicketReference repository="" revision="17708"
 Fixed #17895 -- Made override_settings send the setting_changed signal
 both when a setting is overridden and when it's restored.
 }}}

-- 
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] r17708 - in django/trunk: django/test docs/ref tests/regressiontests/settings_tests

[noreply]

Author: aaugustin
Date: 2012-03-13 16:02:31 -0700 (Tue, 13 Mar 2012)
New Revision: 17708

Modified:
   django/trunk/django/test/utils.py
   django/trunk/docs/ref/signals.txt
   django/trunk/tests/regressiontests/settings_tests/tests.py
Log:
Fixed #17895 -- Made override_settings send the setting_changed signal both 
when a setting is overridden and when it's restored.


Modified: django/trunk/django/test/utils.py
===
--- django/trunk/django/test/utils.py   2012-03-13 22:25:10 UTC (rev 17707)
+++ django/trunk/django/test/utils.py   2012-03-13 23:02:31 UTC (rev 17708)
@@ -167,15 +167,6 @@
 delattr(loader, RESTORE_LOADERS_ATTR)
 
 
-class OverrideSettingsHolder(UserSettingsHolder):
-"""
-A custom setting holder that sends a signal upon change.
-"""
-def __setattr__(self, name, value):
-UserSettingsHolder.__setattr__(self, name, value)
-setting_changed.send(sender=self.__class__, setting=name, value=value)
-
-
 class override_settings(object):
 """
 Acts as either a decorator, or a context manager. If it's a decorator it
@@ -215,10 +206,18 @@
 return inner
 
 def enable(self):
-override = OverrideSettingsHolder(settings._wrapped)
+override = UserSettingsHolder(settings._wrapped)
 for key, new_value in self.options.items():
 setattr(override, key, new_value)
 settings._wrapped = override
+for key, new_value in self.options.items():
+setting_changed.send(sender=settings._wrapped.__class__,
+ setting=key, value=new_value)
 
 def disable(self):
 settings._wrapped = self.wrapped
+for key in self.options:
+new_value = getattr(settings, key, None)
+setting_changed.send(sender=settings._wrapped.__class__,
+ setting=key, value=new_value)
+

Modified: django/trunk/docs/ref/signals.txt
===
--- django/trunk/docs/ref/signals.txt   2012-03-13 22:25:10 UTC (rev 17707)
+++ django/trunk/docs/ref/signals.txt   2012-03-13 23:02:31 UTC (rev 17708)
@@ -477,20 +477,24 @@
 .. data:: django.test.signals.setting_changed
:module:
 
-Sent when some :ref:`settings are overridden ` with the
+This signal is sent when the value of a setting is changed through the
 :meth:`django.test.TestCase.setting` context manager or the
 :func:`django.test.utils.override_settings` decorator/context manager.
 
+It's actually sent twice: when the new value is applied ("setup") and when the
+original value is restored ("teardown").
+
 Arguments sent with this signal:
 
 ``sender``
 The settings handler.
 
 ``setting``
-Same as sender
+The name of the setting.
 
 ``value``
-The new setting value.
+The value of the setting after the change. For settings that initially
+don't exist, in the "teardown" phase, ``value`` is ``None``.
 
 template_rendered
 -

Modified: django/trunk/tests/regressiontests/settings_tests/tests.py
===
--- django/trunk/tests/regressiontests/settings_tests/tests.py  2012-03-13 
22:25:10 UTC (rev 17707)
+++ django/trunk/tests/regressiontests/settings_tests/tests.py  2012-03-13 
23:02:31 UTC (rev 17708)
@@ -132,6 +132,7 @@
 self.assertRaises(AttributeError, getattr, settings, 'TEST')
 with self.settings(TEST='override'):
 self.assertEqual(testvalue, 'override')
+self.assertEqual(testvalue, None)
 
 @override_settings(TEST='override')
 def test_signal_callback_decorator(self):

-- 
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] #17893: GIS installation docs do not cover Ubuntu 11.10

[Django]

#17893: GIS installation docs do not cover Ubuntu 11.10
--+
 Reporter:  jpaulett  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  GIS   |  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 claudep):

 * 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] #9245: Using choices in a mode field forces use of TypedChoiceField in a form field

[Django]

#9245: Using choices in a mode field forces use of TypedChoiceField in a form
field
+
 Reporter:  Tarken  |Owner:  badri
 Type:  Bug |   Status:  reopened
Component:  Forms   |  Version:  1.0
 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 ambv):

 I ended up creating a new patch since the old one used doctests and the
 solution was based on a hardcoded list of form fields that should be
 overriden which basically reintroduced the same problem in a different
 form.

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

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

Re: [Django] #17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh

[Django]

#17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh
---+
 Reporter:  akaihola   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:  fixed
 Keywords:  geodjango postgis  | 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):

 In [17707]:
 {{{
 #!CommitTicketReference repository="" revision="17707"
 Fixed #17584 -- Updated create_template_postgis-debian.sh script for
 PostgreSQL 9.1 installs. Thanks akaihola for the initial patch.

 Backport of r17706 from trunk.
 }}}

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

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

[Changeset] r17707 - django/branches/releases/1.3.X/docs/ref/contrib/gis

[noreply]

Author: claudep
Date: 2012-03-13 15:25:10 -0700 (Tue, 13 Mar 2012)
New Revision: 17707

Modified:
   
django/branches/releases/1.3.X/docs/ref/contrib/gis/create_template_postgis-debian.sh
Log:
Fixed #17584 -- Updated create_template_postgis-debian.sh script for PostgreSQL 
9.1 installs. Thanks akaihola for the initial patch.

Backport of r17706 from trunk.


Modified: 
django/branches/releases/1.3.X/docs/ref/contrib/gis/create_template_postgis-debian.sh
===
--- 
django/branches/releases/1.3.X/docs/ref/contrib/gis/create_template_postgis-debian.sh
   2012-03-13 22:21:38 UTC (rev 17706)
+++ 
django/branches/releases/1.3.X/docs/ref/contrib/gis/create_template_postgis-debian.sh
   2012-03-13 22:25:10 UTC (rev 17707)
@@ -1,5 +1,8 @@
 #!/bin/bash
 
+GEOGRAPHY=0
+POSTGIS_SQL=postgis.sql
+
 # For Ubuntu 8.x and 9.x releases.
 if [ -d "/usr/share/postgresql-8.3-postgis" ]
 then
@@ -11,21 +14,24 @@
 if [ -d "/usr/share/postgresql/8.4/contrib" ]
 then
 POSTGIS_SQL_PATH=/usr/share/postgresql/8.4/contrib
-POSTGIS_SQL=postgis.sql
 fi
 
 # For Ubuntu 10.10 (with PostGIS 1.5)
 if [ -d "/usr/share/postgresql/8.4/contrib/postgis-1.5" ]
 then
 POSTGIS_SQL_PATH=/usr/share/postgresql/8.4/contrib/postgis-1.5
-POSTGIS_SQL=postgis.sql
 GEOGRAPHY=1
-else
-GEOGRAPHY=0
 fi
 
+# For Ubuntu 11.10 / Linux Mint 12 (with PostGIS 1.5)
+if [ -d "/usr/share/postgresql/9.1/contrib/postgis-1.5" ]
+then
+POSTGIS_SQL_PATH=/usr/share/postgresql/9.1/contrib/postgis-1.5
+GEOGRAPHY=1
+fi
+
 createdb -E UTF8 template_postgis && \
-createlang -d template_postgis plpgsql && \
+( createlang -d template_postgis -l | grep plpgsql || createlang -d 
template_postgis plpgsql ) && \
 psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE 
datname='template_postgis';" && \
 psql -d template_postgis -f $POSTGIS_SQL_PATH/$POSTGIS_SQL && \
 psql -d template_postgis -f $POSTGIS_SQL_PATH/spatial_ref_sys.sql && \

-- 
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] r17706 - django/trunk/docs/ref/contrib/gis

[noreply]

Author: claudep
Date: 2012-03-13 15:21:38 -0700 (Tue, 13 Mar 2012)
New Revision: 17706

Modified:
   django/trunk/docs/ref/contrib/gis/create_template_postgis-debian.sh
Log:
Fixed #17584 -- Updated create_template_postgis-debian.sh script for PostgreSQL 
9.1 installs. Thanks akaihola for the initial patch.

Modified: django/trunk/docs/ref/contrib/gis/create_template_postgis-debian.sh
===
--- django/trunk/docs/ref/contrib/gis/create_template_postgis-debian.sh 
2012-03-13 21:49:48 UTC (rev 17705)
+++ django/trunk/docs/ref/contrib/gis/create_template_postgis-debian.sh 
2012-03-13 22:21:38 UTC (rev 17706)
@@ -1,5 +1,8 @@
 #!/bin/bash
 
+GEOGRAPHY=0
+POSTGIS_SQL=postgis.sql
+
 # For Ubuntu 8.x and 9.x releases.
 if [ -d "/usr/share/postgresql-8.3-postgis" ]
 then
@@ -11,21 +14,24 @@
 if [ -d "/usr/share/postgresql/8.4/contrib" ]
 then
 POSTGIS_SQL_PATH=/usr/share/postgresql/8.4/contrib
-POSTGIS_SQL=postgis.sql
 fi
 
 # For Ubuntu 10.10 (with PostGIS 1.5)
 if [ -d "/usr/share/postgresql/8.4/contrib/postgis-1.5" ]
 then
 POSTGIS_SQL_PATH=/usr/share/postgresql/8.4/contrib/postgis-1.5
-POSTGIS_SQL=postgis.sql
 GEOGRAPHY=1
-else
-GEOGRAPHY=0
 fi
 
+# For Ubuntu 11.10 / Linux Mint 12 (with PostGIS 1.5)
+if [ -d "/usr/share/postgresql/9.1/contrib/postgis-1.5" ]
+then
+POSTGIS_SQL_PATH=/usr/share/postgresql/9.1/contrib/postgis-1.5
+GEOGRAPHY=1
+fi
+
 createdb -E UTF8 template_postgis && \
-createlang -d template_postgis plpgsql && \
+( createlang -d template_postgis -l | grep plpgsql || createlang -d 
template_postgis plpgsql ) && \
 psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE 
datname='template_postgis';" && \
 psql -d template_postgis -f $POSTGIS_SQL_PATH/$POSTGIS_SQL && \
 psql -d template_postgis -f $POSTGIS_SQL_PATH/spatial_ref_sys.sql && \

-- 
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] #17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh

[Django]

#17584: Ubuntu 11.10 / Linux Mint 12 update to create_template_postgis-debian.sh
---+
 Reporter:  akaihola   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:  fixed
 Keywords:  geodjango postgis  | 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):

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


Comment:

 In [17706]:
 {{{
 #!CommitTicketReference repository="" revision="17706"
 Fixed #17584 -- Updated create_template_postgis-debian.sh script for
 PostgreSQL 9.1 installs. Thanks akaihola for the initial patch.
 }}}

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

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

Re: [Django] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | 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 aaugustin):

 This improved version is unfortunately blocked by #17895.

-- 
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] #17895: override_settings doesn't send the setting_changed signal when restoring the original value

[Django]

#17895: override_settings doesn't send the setting_changed signal when restoring
the original value
---+
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not super-convinced of the state argument. Would be nice to have a use
 case for it, even hypothetical.

-- 
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] #17895: override_settings doesn't send the setting_changed signal when restoring the original value

[Django]

#17895: override_settings doesn't send the setting_changed signal when restoring
the original value
-+
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  SVN
   Severity:  Release blocker|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Django 1.4 introduces the `override_settings` context manager / decorator.
 When a setting is overridden, it fires the `setting_changed` signal. This
 signal allows to clean up or reset state that depends on a given setting,
 when that setting is changed.

 However, in the current implementation, the signal isn't fired when the
 original value of the setting is restored.

 I think `setting_changed` would be easier to use if it's fired whenever
 the value of a setting is "changed" in a broad sense, that is "overridden"
 or "reset".

 While discussing this on IRC, it was suggested to add an extra argument,
 like `state="pre" / "post"`, to distinguish between the two phases.

 I'm marking this ticket as a release blocker because it would
 significantly change the behavior of `setting_changed`; we must make a
 decision before 1.4.

 It's also a prerequisite for `17882-second-take.patch` on #17882.

 Patch w/ tests and docs attached.

-- 
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] r17705 - django/trunk/docs/releases

[noreply]

Author: julien
Date: 2012-03-13 14:49:48 -0700 (Tue, 13 Mar 2012)
New Revision: 17705

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Fixed #17891 -- Documented a small backwards incompatibility in the 
`password_reset` auth view. Thanks to danfairs and lukegb.

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-13 19:23:52 UTC (rev 17704)
+++ django/trunk/docs/releases/1.4.txt  2012-03-13 21:49:48 UTC (rev 17705)
@@ -961,6 +961,15 @@
 If you're using PUT or DELETE methods in AJAX applications, please see the
 :ref:`instructions about using AJAX and CSRF `.
 
+Password reset view now accepts ``subject_template_name``
+~
+
+The ``password_reset`` view in ``django.contrib.auth`` now accepts a
+``subject_template_name`` parameter, which is passed to the password save form
+as a keyword argument. If you are using this view with a custom password reset
+form, then you will need to ensure your form's ``save()`` method accepts this
+keyword argument.
+
 ``django.core.template_loaders``
 
 

-- 
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] #17891: Password reset email - small backwards incompatiblitity

[Django]

#17891: Password reset email - small backwards incompatiblitity
---+--
 Reporter:  danfairs   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by julien):

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


Comment:

 In [17705]:
 {{{
 #!CommitTicketReference repository="" revision="17705"
 Fixed #17891 -- Documented a small backwards incompatibility in the
 `password_reset` auth view. Thanks to danfairs and lukegb.
 }}}

-- 
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] #17894: create_template_postgis-debian.sh fails on Ubuntu 11.10

[Django]

#17894: create_template_postgis-debian.sh fails on Ubuntu 11.10
--+--
 Reporter:  jpaulett  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
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:   => duplicate


Comment:

 Duplicate of #17584

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

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

Re: [Django] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
---+
 Reporter:  minarets   |Owner:  julien
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+
Changes (by julien):

 * needs_better_patch:  0 => 1
 * severity:  Release blocker => Normal
 * stage:  Ready for checkin => Accepted


Comment:

 Removing the "release blocker" flag to avoid confusion. We are not going
 to ship a fix for this in 1.4. It will stay on my radar for later.

-- 
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] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 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
-+-
Changes (by Fandekasp):

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


Comment:

 @ed.crewe , I couldn't reproduce your problem, I don't understand how
 you're testing your user object permissions. I always do it through
 get_object or dispatch, and didn't get such problem.

 I wrote a test that does basically the same thing, by adding a kwarg in an
 overrided get() instead of get_context_data, and insure that this new
 kwarg isn't lost in ProcessFormView.get(). I don't like my test, so if you
 could give me your use case, I'll replace the test by a proper one.


 I'm wondering if I should do the same with post ? Again, I need to
 understand the use case before doing so.

-- 
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] #13340: patch for updating postgis template script for ubuntu 10.04

[Django]

#13340: patch for updating postgis template script for ubuntu 10.04
--+
 Reporter:  neskiem@… |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.1
 Severity:  Normal|   Resolution:  fixed
 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):

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


Comment:

 This issue has been fixed some time ago by r15520.

-- 
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] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1


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

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

Re: [Django] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:  needsinfo
 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 andi@…):

 Locale settings are all ok.
 As I suspected it was a bug in the apache package of Ubuntu. I have
 reverted to the original code and uploaded (after Apache restart) a file
 containing a German umlaut. Everything went fine.

 Sorry for bothering you with 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] #17891: Password reset email - small backwards incompatiblitity

[Django]

#17891: Password reset email - small backwards incompatiblitity
---+--
 Reporter:  danfairs   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by lukegb):

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


Comment:

 Looks good and applies cleanly here - uploaded the patch file here just in
 case - I dunno what the core team what in terms of patches and pull
 requests.

 Moved to 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] #17813: Implement an opposite method for Entry.objects.latest

[Django]

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

 * owner:  Fandekasp =>


Comment:

 I see your point. Let's wait for a core developer comment

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

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

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

[Django]

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

Comment (by hcarvalhoalves):

 Replying to [comment:8 Fandekasp]:
 > For the attributes, what is odd is to add a Meta.get_latest_by in your
 model when you want to call a earliest(), don't you think ?

 I don't think so. What I '''would''' consider odd, though, is having a
 second, analagous property, `get_earliest_by`, when you can just derive
 one from the other and stay DRY. As long as `ealiest()` is explained in
 the docs as doing the opposite of `latest()`, there's no more room for
 confusion.

 > It's also more flexible to have 2 separate attributes, therefore I
 finally think it's the best approach.

 I'm afraid this is a case were developers expect behaviour to be more
 obvious than flexible. Allowing `latest()` and `earliest()` to return
 different results is guaranteed to be a source of stupid bugs, while
 having no valid use 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] #17236: Documentation of session behavior during login

[Django]

#17236: Documentation of session behavior during login
-+-
 Reporter:  bruth|Owner:
 Type:   |  krzysiumed
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 In [17704]:
 {{{
 #!CommitTicketReference repository="" revision="17704"
 Fixed #17236 -- Clarified that anonymous session data are retained after
 login. Thanks krzysiumed for the patch.
 }}}

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

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

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

[noreply]

Author: claudep
Date: 2012-03-13 12:23:52 -0700 (Tue, 13 Mar 2012)
New Revision: 17704

Modified:
   django/trunk/django/contrib/auth/__init__.py
   django/trunk/docs/topics/auth.txt
Log:
Fixed #17236 -- Clarified that anonymous session data are retained after login. 
Thanks krzysiumed for the patch.

Modified: django/trunk/django/contrib/auth/__init__.py
===
--- django/trunk/django/contrib/auth/__init__.py2012-03-13 17:53:31 UTC 
(rev 17703)
+++ django/trunk/django/contrib/auth/__init__.py2012-03-13 19:23:52 UTC 
(rev 17704)
@@ -55,7 +55,8 @@
 def login(request, user):
 """
 Persist a user id and a backend in the request. This way a user doesn't
-have to reauthenticate on every request.
+have to reauthenticate on every request. Note that data set during
+the anonymous session is retained when the user logs in.
 """
 if user is None:
 user = request.user

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2012-03-13 17:53:31 UTC (rev 17703)
+++ django/trunk/docs/topics/auth.txt   2012-03-13 19:23:52 UTC (rev 17704)
@@ -727,6 +727,9 @@
 using Django's session framework, so, as mentioned above, you'll need to
 make sure to have the session middleware installed.
 
+Note that data set during the anonymous session is retained when the user
+logs in.
+
 This example shows how you might use both
 :func:`~django.contrib.auth.authenticate()` and
 :func:`~django.contrib.auth.login()`::

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

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

[Django]

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

 * needs_better_patch:  1 => 0


Comment:

 Done.

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

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

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

[Django]

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

 * needs_better_patch:  0 => 1


Comment:

 You're right for first, I just went along with jimmysong implementation
 without thinking about that. Will change that now

 For the attributes, what is odd is to add a Meta.get_latest_by in your
 model when you want to call a earliest(), don't you think ? It's also more
 flexible to have 2 separate attributes, therefore I finally think it's the
 best approach. And it doesn't break everybody's code.

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

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

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

[Django]

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

Comment (by hcarvalhoalves):

 For the record: a method named ''first'' is misleading. The antonym for
 "latest" is "earliest". ''first'' sounds too much like you're getting the
 first record (by PK order) instead of by an arbitrary field.

 Also, having 2 different attributes on `Meta` is odd. I don't see why you
 can't just keep `get_latest_by` and get along without breaking everybody's
 code. It will be obvious `earliest` is reciprocal.

-- 
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] #17795: kwargs not passed on by django.views.generic.edit import ProcessFormView

[Django]

#17795: kwargs not passed on by django.views.generic.edit import ProcessFormView
-+-
 Reporter:  ed.crewe@…   |Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * owner:  nobody => Fandekasp
 * cc: lemaire.adrien@… (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] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

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

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


Comment:

 Yeah, I've just re-implemented this feature in the context of another
 ticket and I felt like hcarvalhoalves.

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

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

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

[Django]

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

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


Comment:

 Done. I also added more tests to insure the correct error is raised if no
 Meta.get_first_by or Meta.get_latest_by is defined

-- 
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] #17892: Calling RegexURLResolver.__repr__ takes a lot of time (and memory)

[Django]

#17892: Calling RegexURLResolver.__repr__ takes a lot of time (and memory)
-+--
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4-beta-1
 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 jezdez):

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


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

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

Re: [Django] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

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

Comment (by hcarvalhoalves):

 For a end-user, "past 7 days" essentialy means "show me everything since,
 and including, last ". You don't do the math using hours,
 you compute with whole days. I believe the current behaviour is the most
 expected behaviour, or at least the less surprising one.

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

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

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

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

 * stage:  Accepted => Design decision needed


Comment:

 Replying to [comment:16 julien]:
 > I've also noticed that the same display logic is used on the changelist
 when a file field is in `list_display`.
 [[BR]]

 Uhoh. So this is something I completely missed. It seems that
 display_for_field is implicitly expected to just return a text value, not
 an HTML value.
 If a read only file field is listed in the `list_display` then in the
 admin the link to edit that object vanishes. The HTML ends up looking like
 filepath/filename. Worse, if it's the only thing listed in
 `list_display` it leaves the end user no obvious way to go and actually
 edit the object.

 An icky feeling fix would be to go and put the special case logic for this
 in contrib.admin.helpers.AdminReadonlyField.contents which is what's being
 called to display it on the modify object page. After some discussion with
 julien though, I'm kicking this back to DDN. Maybe at some point the
 AdminReadonlyField class will be refactored to allow for this kind of
 flexibility.

-- 
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] #17894: create_template_postgis-debian.sh fails on Ubuntu 11.10

[Django]

#17894: create_template_postgis-debian.sh fails on Ubuntu 11.10
--+--
 Reporter:  jpaulett  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by jpaulett):

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


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

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

Re: [Django] #17893: GIS installation docs do not cover Ubuntu 11.10

[Django]

#17893: GIS installation docs do not cover Ubuntu 11.10
--+--
 Reporter:  jpaulett  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by jpaulett):

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


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

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

[Django] #17894: create_template_postgis-debian.sh fails on Ubuntu 11.10

[Django]

#17894: create_template_postgis-debian.sh fails on Ubuntu 11.10
+
 Reporter:  jpaulett|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  GIS |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Ubuntu 11.10 upgraded to PostgreSQL 9.1, thus the path to the PostGIS
 files have changed again (to
 /usr/share/postgresql/9.1/contrib/postgis-1.5)

 Additionally it appears that plpsql is now installed in the template
 database by default, resulting the failure of the createlang command,
 which causes following commands to not be executed:

 {{{
 createlang: language "plpgsql" is already installed in database
 "template_postgis"
 }}}

 On a fresh Ubuntu 11.10 install:

 {{{
 $ sudo -u postgres psql
 psql (9.1.3)
 Type "help" for help.

 postgres=# \dL
   List of languages
   Name   |  Owner   | Trusted
 -+--+-
  plpgsql | postgres | t
 (1 row)

 }}}

 The attached patch adds the path to PostgreSQL 9.1 and only runs
 createlang for older version.

-- 
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] #17893: GIS installation docs do not cover Ubuntu 11.10

[Django]

#17893: GIS installation docs do not cover Ubuntu 11.10
+
 Reporter:  jpaulett|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  GIS |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Ubuntu 11.10 upgraded PostgreSQL to 9.1 (from 8.4) the current
 documentation only includes instructions up to 10.10.

 The attached patch adds new apt-get entry for 11.10 using the correct
 version of PostgreSQL.

-- 
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] r17703 - in django/trunk: django/conf docs docs/faq docs/howto docs/internals docs/internals/contributing docs/internals/contributing/writing-code docs/intro docs/man docs/misc docs/ref d

[noreply]

Author: claudep
Date: 2012-03-13 10:53:31 -0700 (Tue, 13 Mar 2012)
New Revision: 17703

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/docs/faq/general.txt
   django/trunk/docs/faq/install.txt
   django/trunk/docs/glossary.txt
   django/trunk/docs/howto/index.txt
   django/trunk/docs/index.txt
   django/trunk/docs/internals/contributing/bugs-and-features.txt
   django/trunk/docs/internals/contributing/committing-code.txt
   django/trunk/docs/internals/contributing/index.txt
   django/trunk/docs/internals/contributing/new-contributors.txt
   django/trunk/docs/internals/contributing/triaging-tickets.txt
   django/trunk/docs/internals/contributing/writing-code/branch-policy.txt
   django/trunk/docs/internals/contributing/writing-code/submitting-patches.txt
   django/trunk/docs/internals/svn.txt
   django/trunk/docs/intro/overview.txt
   django/trunk/docs/intro/whatsnext.txt
   django/trunk/docs/man/gather_profile_stats.1
   django/trunk/docs/misc/distributions.txt
   django/trunk/docs/ref/contrib/contenttypes.txt
   django/trunk/docs/ref/contrib/flatpages.txt
   django/trunk/docs/ref/contrib/gis/db-api.txt
   django/trunk/docs/ref/contrib/gis/geoquerysets.txt
   django/trunk/docs/ref/contrib/gis/install.txt
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/docs/ref/contrib/redirects.txt
   django/trunk/docs/ref/contrib/syndication.txt
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/ref/validators.txt
   django/trunk/docs/releases/0.95.txt
   django/trunk/docs/releases/0.96.txt
   django/trunk/docs/releases/1.0-alpha-1.txt
   django/trunk/docs/releases/1.0-alpha-2.txt
   django/trunk/docs/releases/1.0-beta-2.txt
   django/trunk/docs/releases/1.0-beta.txt
   django/trunk/docs/releases/1.0-porting-guide.txt
   django/trunk/docs/releases/1.0.1.txt
   django/trunk/docs/releases/1.0.txt
   django/trunk/docs/releases/1.1-alpha-1.txt
   django/trunk/docs/releases/1.1-beta-1.txt
   django/trunk/docs/releases/1.1-rc-1.txt
   django/trunk/docs/releases/1.1.txt
   django/trunk/docs/releases/1.2-alpha-1.txt
   django/trunk/docs/releases/1.2-beta-1.txt
   django/trunk/docs/releases/1.2-rc-1.txt
   django/trunk/docs/releases/1.2.4.txt
   django/trunk/docs/releases/1.2.5.txt
   django/trunk/docs/releases/1.3-alpha-1.txt
   django/trunk/docs/releases/1.3-beta-1.txt
   django/trunk/docs/releases/1.3.txt
   django/trunk/docs/releases/1.4-alpha-1.txt
   django/trunk/docs/releases/1.4-beta-1.txt
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/class-based-views.txt
   django/trunk/docs/topics/db/models.txt
   django/trunk/docs/topics/db/queries.txt
   django/trunk/docs/topics/generic-views.txt
   django/trunk/docs/topics/http/urls.txt
   django/trunk/docs/topics/install.txt
Log:
Replaced http by https in djangoproject.com links

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2012-03-13 17:52:48 UTC (rev 
17702)
+++ django/trunk/django/conf/global_settings.py 2012-03-13 17:53:31 UTC (rev 
17703)
@@ -401,7 +401,7 @@
 # The User-Agent string to use when checking for URL validity through the
 # isExistingURL validator.
 from django import get_version
-URL_VALIDATOR_USER_AGENT = "Django/%s (http://www.djangoproject.com)" % 
get_version()
+URL_VALIDATOR_USER_AGENT = "Django/%s (https://www.djangoproject.com)" % 
get_version()
 
 # The tablespaces to use for each model when not specified otherwise.
 DEFAULT_TABLESPACE = ''

Modified: django/trunk/docs/faq/general.txt
===
--- django/trunk/docs/faq/general.txt   2012-03-13 17:52:48 UTC (rev 17702)
+++ django/trunk/docs/faq/general.txt   2012-03-13 17:53:31 UTC (rev 17703)
@@ -176,7 +176,7 @@
 versions of those reST documents, so the docs on the Django site may offer more
 information than the docs that come with the latest Django release.
 
-.. _stored in revision control: 
http://code.djangoproject.com/browser/django/trunk/docs
+.. _stored in revision control: 
https://code.djangoproject.com/browser/django/trunk/docs
 
 Where can I find Django developers for hire?
 
@@ -188,4 +188,4 @@
 If you want to find Django-capable people in your local area, try
 http://djangopeople.net/ .
 
-.. _developers for hire page: 
http://code.djangoproject.com/wiki/DevelopersForHire
+.. _developers for hire page: 
https://code.djangoproject.com/wiki/DevelopersForHire

Modified: django/trunk/docs/faq/install.txt
===
--- django/trunk/docs/faq/install.txt   2012-03-13 17:52:48 UTC (rev 17702)
+++ django/trunk/docs/faq/install.txt   2012-03-13 17:53:31 UTC (rev 17703)
@@ -10,8 +10,8 @@
 #. Check out the rest of the :doc:`documentation `, and `ask 
questions`_ if you
run into trouble.
 
-.. _`Download the code`: 

Re: [Django] #16329: Django doesn't initialize two databases with the same name, port and host

[Django]

#16329: Django doesn't initialize two databases with the same name, port and 
host
---+
 Reporter:  canassa|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by ramiro):

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


Comment:

 In [17702]:
 {{{
 #!CommitTicketReference repository="" revision="17702"
 Fixed #16329 -- Fixed detection of transaction-handling capabilities when
 all test databases are sqlite3, in-memory.

 Thanks canassa for the report and agriffis (#17762) and lrekucki (in
 #17758) for their contribution to the fix.
 }}}

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

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

[Changeset] r17702 - in django/trunk: django/db/backends/sqlite3 tests/regressiontests/test_runner

[noreply]

Author: ramiro
Date: 2012-03-13 10:52:48 -0700 (Tue, 13 Mar 2012)
New Revision: 17702

Modified:
   django/trunk/django/db/backends/sqlite3/creation.py
   django/trunk/tests/regressiontests/test_runner/tests.py
Log:
Fixed #16329 -- Fixed detection of transaction-handling capabilities when all 
test databases are sqlite3, in-memory.

Thanks canassa for the report and agriffis (#17762) and lrekucki (in #17758) 
for their contribution to the fix.

Modified: django/trunk/django/db/backends/sqlite3/creation.py
===
--- django/trunk/django/db/backends/sqlite3/creation.py 2012-03-13 17:35:00 UTC 
(rev 17701)
+++ django/trunk/django/db/backends/sqlite3/creation.py 2012-03-13 17:52:48 UTC 
(rev 17702)
@@ -72,3 +72,18 @@
 
 def set_autocommit(self):
 self.connection.connection.isolation_level = None
+
+def test_db_signature(self):
+"""
+Returns a tuple that uniquely identifies a test database.
+
+This takes into account the special cases of ":memory:" and "" for
+SQLite since the databases will be distinct despite having the same
+TEST_NAME. See http://www.sqlite.org/inmemorydb.html
+"""
+settings_dict = self.connection.settings_dict
+test_dbname = self._get_test_db_name()
+sig = [self.connection.settings_dict['NAME']]
+if test_dbname == ':memory:':
+sig.append(self.connection.alias)
+return tuple(sig)

Modified: django/trunk/tests/regressiontests/test_runner/tests.py
===
--- django/trunk/tests/regressiontests/test_runner/tests.py 2012-03-13 
17:35:00 UTC (rev 17701)
+++ django/trunk/tests/regressiontests/test_runner/tests.py 2012-03-13 
17:52:48 UTC (rev 17702)
@@ -11,6 +11,7 @@
 from django.core.management import call_command
 from django.test import simple
 from django.test.simple import DjangoTestSuiteRunner, get_tests
+from django.test.testcases import connections_support_transactions
 from django.test.utils import get_warnings_state, restore_warnings_state
 from django.utils import unittest
 from django.utils.importlib import import_module
@@ -262,3 +263,38 @@
 "Test for #12658 - Tests with ImportError's shouldn't fail silently"
 module = import_module(TEST_APP_ERROR)
 self.assertRaises(ImportError, get_tests, module)
+
+
+class Sqlite3InMemoryTestDbs(unittest.TestCase):
+def test_transaction_support(self):
+"""Ticket #16329: sqlite3 in-memory test databases"""
+from django import db
+old_db_connections = db.connections
+for option in ('NAME', 'TEST_NAME'):
+try:
+db.connections = db.ConnectionHandler({
+'default': {
+'ENGINE': 'django.db.backends.sqlite3',
+option: ':memory:',
+},
+'other': {
+'ENGINE': 'django.db.backends.sqlite3',
+option: ':memory:',
+},
+})
+other = db.connections['other']
+self.assertEqual(other.features.supports_transactions, None)
+DjangoTestSuiteRunner(verbosity=0).setup_databases()
+# Transaction support should be properly initialised for the 
'other' DB
+self.assertNotEqual(
+other.features.supports_transactions,
+None,
+"DATABASES setting '%s' option set to sqlite3's ':memory:' 
value causes problems with transaction support detection." % option
+)
+# And all the DBs should report that they support transactions
+self.assertTrue(
+connections_support_transactions(),
+"DATABASES setting '%s' option set to sqlite3's ':memory:' 
value causes problems with transaction support detection." % option
+)
+finally:
+db.connections = old_db_connections

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

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

[Django]

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

 * owner:  nobody => Fandekasp
 * cc: lemaire.adrien@… (added)
 * status:  reopened => new


Comment:

 I read your code. Tests need to be renamed, it's not LatestTests anymore
 but FirstOrLatestTests.
 Same goes for the model.Options.get_latest_by. Don't make any sense to ask
 for a get_latest_by parameter when performing and first() action.

 Two solutions:
  - rename get_latest_by in get_first_or_latest_by . Backward incompatible,
 but that options touch a very tiny bit of code, and this would be the
 cleanest solution.
  - add a new get_first_by field in Options that will behave like
 get_latest_by.

 I'll add a new patch with the 2nd solution, and will change it if the core
 developers agree with the first one.

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

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

[Changeset] r17701 - in django/trunk: . docs/internals

[noreply]

Author: claudep
Date: 2012-03-13 10:35:00 -0700 (Tue, 13 Mar 2012)
New Revision: 17701

Modified:
   django/trunk/AUTHORS
   django/trunk/docs/internals/committers.txt
Log:
Add myself to committers

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2012-03-13 16:33:56 UTC (rev 17700)
+++ django/trunk/AUTHORS2012-03-13 17:35:00 UTC (rev 17701)
@@ -28,6 +28,7 @@
 * Paul McMillan
 * Julien Phalip
 * Aymeric Augustin
+* Claude Paroz
 
 More information on the main contributors to Django can be found in
 docs/internals/committers.txt.
@@ -398,7 +399,6 @@
 oggie rob 
 oggy 
 Jay Parlar 
-Claude Paroz 
 Carlos Eduardo de Paula 
 John Paulett 
 pavithran s 

Modified: django/trunk/docs/internals/committers.txt
===
--- django/trunk/docs/internals/committers.txt  2012-03-13 16:33:56 UTC (rev 
17700)
+++ django/trunk/docs/internals/committers.txt  2012-03-13 17:35:00 UTC (rev 
17701)
@@ -342,6 +342,19 @@
 .. _Aymeric Augustin: http://myks.org/
 .. _management consulting company: http://www.polyconseil.fr/
 
+`Claude Paroz`_
+Claude is a former teacher who fell in love with free software at the
+beginning of the 21st century. He's now working as freelancer in Web
+development in his native Switzerland. He has found in Django a perfect
+match for his needs of a stable, clean, documented and well-maintained Web
+framework.
+
+He's also helping the GNOME Translation Project as maintainer of the
+Django-based `l10n.gnome.org`_.
+
+.. _Claude Paroz: http://www.2xlibre.net
+.. _l10n.gnome.org: http://l10n.gnome.org
+
 Specialists
 ---
 

-- 
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] #16329: Django doesn't initialize two databases with the same name, port and host

[Django]

#16329: Django doesn't initialize two databases with the same name, port and 
host
---+
 Reporter:  canassa|Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Testing framework  |  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 ramiro):

 * has_patch:  0 => 1
 * stage:  Design decision needed => 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] #17768: Explain the expected failure on UpdateViewTests.test_update_put

[Django]

#17768: Explain the expected failure on UpdateViewTests.test_update_put
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Generic views|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 In [17700]:
 {{{
 #!CommitTicketReference repository="" revision="17700"
 Fixed #17768 -- Add a comment about an expected failure in generic_views
 tests
 }}}

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

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

[Changeset] r17700 - django/trunk/tests/regressiontests/generic_views

[noreply]

Author: claudep
Date: 2012-03-13 09:33:56 -0700 (Tue, 13 Mar 2012)
New Revision: 17700

Modified:
   django/trunk/tests/regressiontests/generic_views/edit.py
Log:
Fixed #17768 -- Add a comment about an expected failure in generic_views tests

Modified: django/trunk/tests/regressiontests/generic_views/edit.py
===
--- django/trunk/tests/regressiontests/generic_views/edit.py2012-03-13 
06:59:04 UTC (rev 17699)
+++ django/trunk/tests/regressiontests/generic_views/edit.py2012-03-13 
16:33:56 UTC (rev 17700)
@@ -126,6 +126,10 @@
 
 res = self.client.put('/edit/author/%d/update/' % a.pk,
 {'name': 'Randall Munroe (author of xkcd)', 'slug': 
'randall-munroe'})
+# Here is the expected failure. PUT data are not processed in any 
special
+# way by django. So the request will equal to a POST without data, 
hence
+# the form will be invalid and redisplayed with errors (status code 
200).
+# See also #12635
 self.assertEqual(res.status_code, 302)
 self.assertRedirects(res, 'http://testserver/list/authors/')
 self.assertQuerysetEqual(Author.objects.all(), [''])

-- 
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] #5710: dumpdata/loaddata fails with many-to-many tables on postgresql

[Django]

#5710: dumpdata/loaddata fails with many-to-many tables on postgresql
-+-
 Reporter:  davep@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  manage.py loaddata   |  checkin
  dumpdata postgresql|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Revert spam (that I'm going to delete).

-- 
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] #5710: dumpdata/loaddata fails with many-to-many tables on postgresql

[Django]

#5710: dumpdata/loaddata fails with many-to-many tables on postgresql
-+-
 Reporter:  davep@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  manage.py loaddata   |  checkin
  dumpdata postgresql|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  fixed =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 Don't compare yourself to famous people or movie stars when thinking about
 beauty. Beauty is certainly viewed differently by different people. Be
 happy about your body in its current situation.  amazon coupons
 http://www.facebook.com/AmazonCouponCodeOptions

-- 
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] #17892: Calling RegexURLResolver.__repr__ takes a lot of time (and memory)

[Django]

#17892: Calling RegexURLResolver.__repr__ takes a lot of time (and memory)
-+
 Reporter:  milosu   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.4-beta-1
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 I have an application which has about 70K RegexURLPatterns.

 When I try to access some non-existent url in this app under Django
 1.4RC1, it takes a huge amount of time - I mean 1 or 2 minutes - to
 generate the technical 404 response and also the memory consumption goes
 from 220MB to something about 460MB.

 The problem is in a call to RegexURLResolver.__repr__, which is called
 about 3 times during the technical 404 debug response. It looks like the
 whole RegexURLResolver including all its sub-patterns is being recursively
 traversed during a call to __repr__.

 I had to patch RegexURLResolver.__repr__ to cut this CPU overhead.

 Patch attached, but I'm not sure how to write a test case for it.

 I'm also attaching the profiling results of unpatched Django 1.4RC.

 I'm upgrading from Django 1.2.3 so I'm not sure if this behaviour is
 present in 1.3 or if it is new to 1.4, but from my point of view this is a
 release blocker.

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

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

Re: [Django] #14341: Session middleware raises exception when unit testing HttpResponseForbidden

[Django]

#14341: Session middleware raises exception when unit testing 
HttpResponseForbidden
---+--
 Reporter:  dikbrouwer |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  1.2
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by dikbrouwer):

 I can't reproduce it either, it seems to work fine for me know. Perhaps I
 was indeed returning a class, basic mistake. Sorry for the irrelevant bug
 report in that 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] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
 Reporter:  lrekucki |Owner:  Alex
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 tmitchell):

 Any known edge cases should now be resolved in my branch, sorry to imply
 that I left things hanging.  I've run the test case over about 16
 different seeds and it passes all, minus the ORM one.  I did not have time
 to dive into the underlying source of the ORM bug. I will try to carve
 some time out to noodle on it this week while the sprints are happening.

-- 
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] #16329: Django doesn't initialize two databases with the same name, port and host

[Django]

#16329: Django doesn't initialize two databases with the same name, port and 
host
-+-
 Reporter:  canassa  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by agriffis):

 * cc: aron@… (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] #17416: inlineformset_factory doesn't allow the widgets argument

[Django]

#17416: inlineformset_factory doesn't allow the widgets argument
+
 Reporter:  jacob   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by anonymous):

 There is a work around for this bug/feature,
 1) Create a ModelForm with the requested widget
 2) Pass the ModelForm as form argument and voila, the widget works

 in models.py

 class SomeForm(ModelForm):
 class Meta:
 model = Something
 widgets = {
'level' : forms.Select(choices=SOME_CHOICES)
}


 in views.py

 SomeFormsetFactory = inlineformset_factory(Parent, Something,
 form=SomeForm)

-- 
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] #16317: Self-referencing model with natural key: dumpdata can't resolve dependencies

[Django]

#16317: Self-referencing model with natural key: dumpdata can't resolve
dependencies
--+
 Reporter:  DrMeers   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  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 anonymous):

 the patch is ready for current trunk 1.4 alpha

-- 
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] #17256: ContentTypeManager.get_by_natural_key method doesn't cache

[Django]

#17256: ContentTypeManager.get_by_natural_key method doesn't cache
-+-
 Reporter:  defaultwombat|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  cache contenttypes   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 Replying to [comment:6 davide@…]:
 > Any chance for this fix to be backported in 1.3.X?

 Unfortunately no.

-- 
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] #17256: ContentTypeManager.get_by_natural_key method doesn't cache

[Django]

#17256: ContentTypeManager.get_by_natural_key method doesn't cache
-+-
 Reporter:  defaultwombat|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  cache contenttypes   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by davide@…):

 * status:  closed => reopened
 * version:  SVN => 1.3
 * resolution:  fixed =>


Comment:

 Any chance for this fix to be backported in 1.3.X?

-- 
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] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  DecimalField bug |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Old description:

> For a model field created as :: models.DecimalField(max_digits = 200,
> decimal_places = 100, blank = False, null = False)
> While using admin interface to insert a record involving such a
> DecimalField, the format changes (loss of precision and it uses
> scientific notation (even in the database)) (Please note - it works
> properly for low precision values (example - .987654321001234) - but for
> larger precision values (probably 15 decimal_places or more) it results
> in loss of precision)
>
> django version 1.3.1 and 1.4c1 (don't know about older versions);
> python 2.6.6;
> linux;

New description:

 For a model field created as
 {{{
 models.DecimalField(max_digits = 200, decimal_places = 100, blank = False,
 null = False)
 }}}

 While using admin interface to insert a record involving such a
 !DecimalField, the format changes (loss of precision and it uses
 scientific notation (even in the database)) (Please note - it works
 properly for low precision values (example - .987654321001234) - but for
 larger precision values (probably 15 decimal_places or more) it results in
 loss of precision)

 * django version 1.3.1 and 1.4c1 (don't know about older versions);
 * python 2.6.6;
 * linux;

--

Comment (by ramiro):

 Would be acceptable to "fix" this by documenting the limitations of the
 three database engine/adaptors in the DB notes document?

-- 
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] #17762: Multi-db apps (no Django test suite) testing fails to create in-memory sqlite DBs

[Django]

#17762: Multi-db apps (no Django test suite) testing fails to create in-memory
sqlite DBs
-+-
 Reporter:  agriffis |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by ramiro):

 Replying to [comment:9 agriffis]:

 >
 > > Now I realise you are using ":memory:" for the NAME keys in DATABASES.
 That's an odd setup it means all your production databases are no
 persistent.
 >
 > Actually they're test-specific settings. In production that project had
 real databases...
 >
 > Regarding ticket #16329 I agree this is a duplicate of that ticket.
 Sorry I didn't find that one when I looked. I think the patch in this
 ticket, once unbroken, might be the most correct way to fix the problem.
 Let me know if you'd like me to repair it and attach it over there.

 I actually have a patch based on your code combined with something
 lrecucki did for #17758 in a GitHub fork, still trying to find a way to
 write tests for it. Thanks!

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

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

[Django] #17891: Password reset email - small backwards incompatiblitity

[Django]

#17891: Password reset email - small backwards incompatiblitity
---+
 Reporter:  danfairs   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 This feature:

   https://code.djangoproject.com/ticket/12202

 introduced a small backwards incompatibility for those users whose
 application have custom password reset forms - the save() method on the
 form now needs to take an extra parameter. This isn't noted in the
 backwards incompatible changes.

 I've prepared a small note in those docs, in this pull request:

   https://github.com/django/django/pull/124

-- 
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] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
 Reporter:  lrekucki |Owner:  Alex
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 lrekucki):

 Thanks :), I'm still buried in other stuff, but could you give some
 examples of "more edge cases over various other seeds.", so I can
 reproduce them ? I'll probably have some time at the end of the week to
 work on this (if no one beats me to it). For the record, I originally
 tested on Python 2.6.8;

 As for the ORM bug, do you guys have any concrete approach in mind? My
 feeling is, that avoiding this issue in another way would involve larger
 changes in how the ORM constructs joins and subqueries. As this is were
 most ORM bugs tend appear, I wanted to make as little changes as possible
 to avoid introducing new ones. Maybe it would be better to split this out
 into a new 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] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
 Reporter:  lrekucki |Owner:  Alex
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 tmitchell):

 * cc: taylor.mitchell@… (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] #17758: Do not depend on dict order in test suite

[Django]

#17758: Do not depend on dict order in test suite
-+
 Reporter:  lrekucki |Owner:  Alex
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 tmitchell):

 I picked this effort up at the PyCon sprints.  Found a few more edge cases
 over various other seeds.  The ORM changes were reverted so we can
 investigate the core issue and see if there's another way to attack it.

 I also found a difference in 2.7.3 that's not a result of the randomized
 hashing.  This maybe should be a separate ticket.

 My branches:
  * https://github.com/tmitchell/django/tree/randomhash_fixes
  * https://github.com/tmitchell/django/tree/python273_fixes

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

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

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

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

 * needs_better_patch:  0 => 1


Comment:

 Thank you, Paul. I realized the test was failing for me because of the
 hardcoded "media/" in the url path. Using the string variable
 `STORAGE_URL` fixes that (see patch above).

 I've also noticed that the same display logic is used on the changelist
 when a file field is in `list_display`. It'd be great to write an extra
 test to cover that test. Other than that, the patch looks great!

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

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

Re: [Django] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

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

 * has_patch:  0 => 1


Comment:

 After some discussion with Paul at the sprints, we decided to deprecate
 Python-Markdown<2.1

 The "safe" arg to the filter in the patches just attached enables both the
 safe_mode=True and enable_attributes=False in tandem

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | 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 aaugustin):

 I can reproduce the failure locally under MySQL but not under PostgreSQL.
 I don't understand why yet...

 {{{

 (django-dev)myk@mYk tests % PYTHONPATH=.. python2.7 runtests.py
 --settings=test_mysql admin_filters cache timezones
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 
F..sss..s..s.sss
 ==
 FAIL: test_datefieldlistfilter_with_time_zone_support
 (regressiontests.admin_filters.tests.ListFiltersTests)
 --
 Traceback (most recent call last):
   File "/Users/myk/Documents/dev/django-trunk/django/test/utils.py", line
 214, in inner
 return test_func(*args, **kwargs)
   File "/Users/myk/Documents/dev/django-
 trunk/tests/regressiontests/admin_filters/tests.py", line 227, in
 test_datefieldlistfilter_with_time_zone_support
 self.test_datefieldlistfilter()
   File "/Users/myk/Documents/dev/django-
 trunk/tests/regressiontests/admin_filters/tests.py", line 154, in
 test_datefieldlistfilter
 self.assertEqual(list(queryset), [self.django_book,
 self.djangonaut_book])
 AssertionError: Lists differ: [] != [, , ]

 --
 Ran 336 tests in 56.977s

 FAILED (failures=1, skipped=44)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 PYTHONPATH=.. python2.7 runtests.py --settings=test_mysql admin_filters
 cache  12,88s user 1,65s system 22% cpu 1:03,86 total
 (django-dev)myk@mYk tests % PYTHONPATH=.. python2.7 runtests.py
 --settings=test_postgresql admin_filters cache timezones
 Creating test database for alias 'default'...
 Got an error creating the test database: database "test_django" already
 exists

 Type 'yes' if you would like to try deleting the test database
 'test_django', or 'no' to cancel: yes
 Destroying old test database 'default'...
 
.s.s.ss..s..s.s...ss
 --
 Ran 336 tests in 72.750s

 OK (skipped=41)
 Destroying test database for alias 'default'...
 PYTHONPATH=.. python2.7 runtests.py --settings=test_postgresql
 admin_filters   22,06s user 1,99s system 30% cpu 1:19,27 total
 }}}

-- 
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] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  DecimalField bug |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 This problem exists for postgres and mysql too (along with sqlite3).

 for postgres - limit is up to 131072 digits before the decimal point; up
 to 16383 digits after the decimal point (from postgres website -
 http://www.postgresql.org/docs/9.1/static/datatype-numeric.html#DATATYPE-
 NUMERIC-TABLE)

 similarly docs on the mysql site mention that a decimal field has a limit
 of 65 decimal places (but I do not know anything else as I haven't used
 mysql)

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | 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 aaugustin):

 * status:  closed => reopened
 * needs_better_patch:  0 => 1
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 The fix appears incorrect: http://ci.djangoproject.com/job/Django/882/

-- 
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] #17890: django.contrib.admin.site extra_context

[Django]

#17890: django.contrib.admin.site extra_context
+
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  SVN
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by claudep):

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


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

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

Re: [Django] #14341: Session middleware raises exception when unit testing HttpResponseForbidden

[Django]

#14341: Session middleware raises exception when unit testing 
HttpResponseForbidden
---+--
 Reporter:  dikbrouwer |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  1.2
 Severity:  Normal |   Resolution:  worksforme
 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 gerdemb):

 * cc: gerdemb (added)
 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 I also encountered this error and discovered the problem was in my code.
 Instead of returning an HttpResponseForbidden() instance from my
 middleware, I was returning a HttpResponseForbidden class.

 {{{
 class MyMiddleware:
 def process_request(self, request):
 # Correct
 return HttpResponseForbidden()
 # Incorrect
 return HttpResponseForbidden
 }}}

 Although the error was in my code, Django could have provided a more
 helpful error message perhaps by catching the incorrect response type
 sooner.

-- 
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] #17890: django.contrib.admin.site extra_context

[Django]

#17890: django.contrib.admin.site extra_context
+
 Reporter:  riccardodivirgilio  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.admin   |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 hi, in django.contrib.admin.site the method  password_change do not
 support extra_context, i think it's a minor bug to be fixed.

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   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 aaugustin):

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


Comment:

 In [17699]:
 {{{
 #!CommitTicketReference repository="" revision="17699"
 Fixed #17882 -- Reopened the database connection when a test changes time
 zone settings. Thanks brodie for the report.
 }}}

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

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

[Changeset] r17699 - in django/trunk: django/test tests/modeltests/timezones

[noreply]

Author: aaugustin
Date: 2012-03-12 23:59:04 -0700 (Mon, 12 Mar 2012)
New Revision: 17699

Modified:
   django/trunk/django/test/signals.py
   django/trunk/tests/modeltests/timezones/tests.py
Log:
Fixed #17882 -- Reopened the database connection when a test changes time zone 
settings. Thanks brodie for the report.


Modified: django/trunk/django/test/signals.py
===
--- django/trunk/django/test/signals.py 2012-03-13 03:48:20 UTC (rev 17698)
+++ django/trunk/django/test/signals.py 2012-03-13 06:59:04 UTC (rev 17699)
@@ -1,3 +1,5 @@
+from django.conf import settings
+from django.db import close_connection
 from django.dispatch import Signal
 
 template_rendered = Signal(providing_args=["template", "context"])
@@ -3,2 +5,9 @@
 
 setting_changed = Signal(providing_args=["setting", "value"])
+
+# Close the database connection to re-establish it with the proper time zone.
+def close_connection_on_time_zone_change(**kwargs):
+if (kwargs['setting'] == 'USE_TZ'
+or (kwargs['setting'] == 'TIME_ZONE' and not settings.USE_TZ)):
+close_connection()
+setting_changed.connect(close_connection_on_time_zone_change)

Modified: django/trunk/tests/modeltests/timezones/tests.py
===
--- django/trunk/tests/modeltests/timezones/tests.py2012-03-13 03:48:20 UTC 
(rev 17698)
+++ django/trunk/tests/modeltests/timezones/tests.py2012-03-13 06:59:04 UTC 
(rev 17699)
@@ -63,8 +63,6 @@
 self._old_tz = os.environ.get('TZ')
 os.environ['TZ'] = 'Africa/Nairobi'
 time.tzset()
-# Create a new cursor, for test cases that change the value of USE_TZ.
-connection.close()
 
 @classmethod
 def tearDownClass(self):

-- 
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] #17889: Go to "/admin/" on your local domain not working.

[Django]

#17889: Go to "/admin/" on your local domain not working.
-+-
 Reporter:  sumaiyahashmi@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  tutorial admin   | Triage Stage:
  local domain   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Please see: 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.

Re: [Django] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
-+-
 Reporter:  shelldweller |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.localflavor  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * cc: lemaire.adrien@… (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] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
-+-
 Reporter:  shelldweller |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.localflavor  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * needs_tests:  1 => 0
 * 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] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Fandekasp):

 * needs_docs:  1 => 0


Comment:

 tests pass with python2.5 and python 2.6, but fail with python 2.7

 Documentation is ok.

-- 
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] #17889: Go to "/admin/" on your local domain not working.

[Django]

#17889: Go to "/admin/" on your local domain not working.
-+-
 Reporter:  sumaiyahashmi@…  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Uncategorized|Version:  1.3
 Severity:  Normal   |   Keywords:  tutorial admin local domain
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 From Tutorial 2:
 "Now, open a Web browser and go to "/admin/" on your local domain -- e.g.,
 http://127.0.0.1:8000/admin/. You should see the admin's login
 screen:"[[Image(https://docs.djangoproject.com/en/dev/_images/admin01.png)]]

 I don't see that image. Rather, when I go to http://127.0.0.1:8000/admin/
 in my Firefox browser, I get this message:
 "Unable to connect. Firefox can't establish a connection to the server at
 127.0.0.1:8000."

 Am I going to the wrong address? How can I 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.