Re: [Django] #14608: Adding a INPhoneNumberField to indian localflavor

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  assigned
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  1
Patch needs improvement:  0|
---+---
Changes (by julien):

 * type:   => New feature
 * severity:   => Normal
 * needs_tests:  0 => 1


Comment:

 Thanks for this suggestion. Could you write some tests for this, either in
 source:django/trunk/tests/regressiontests/localflavor or
 source:django/trunk/tests/regressiontests/forms/localflavor ?

-- 
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] #15637: Add a require_safe decorator for views to accept GET or HEAD

[Django]

#15637: Add a require_safe decorator for views to accept GET or HEAD
-+-
   Reporter:  aaugustin  |Owner:  nobody
   Type:  New feature|   Status:  new
  Milestone: |Component:  HTTP handling
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Ready for checkin  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Great work, thank you. I've just made a few minor improvements to the doc.

-- 
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] #15698: Inconsistant handling of context_object_name in paginated MultipleObjectMixin

[Django]

#15698: Inconsistant handling of context_object_name in paginated
MultipleObjectMixin
-+-
   Reporter:  etianen|Owner:  etianen
   Type:  Bug|   Status:  assigned
  Milestone: |Component:  Generic views
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Design |Has patch:  1
  decision needed|  Needs tests:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Design decision needed


Comment:

 On a second thought, having two variables (for example "object_list" and
 "book_list" in your patch) pointing to the same thing doesn't feel very
 pythonic. Ideally I'd get rid of "object_list", but that would break
 backwards compatibility. I'd like to hear more viewpoints about this
 before proceeding further. Adding doc would still be useful though.

 Marking as DDN for now as per my concern about the potential
 "unpythonicity". If someone -- other than etianen, the reporter =) --
 thinks this is not a big deal, then please move back 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] #15698: Inconsistant handling of context_object_name in paginated MultipleObjectMixin

[Django]

#15698: Inconsistant handling of context_object_name in paginated
MultipleObjectMixin
+-
   Reporter:  etianen   |Owner:  etianen
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Generic views
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  1 |  Needs tests:  0
Patch needs improvement:  0 |
+-
Changes (by julien):

 * needs_docs:  0 => 1


Comment:

 Thanks, the patch looks good. Could you also update the doc, in particular
 in http://docs.djangoproject.com/en/dev/topics/pagination/ ?

-- 
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] #15713: Adding new polish localflavor field PLNationalIDCardNumberField

[Django]

#15713: Adding new polish localflavor field PLNationalIDCardNumberField
-+-
   Reporter:  xtrqt  |Owner:  xtrqt
   Type:  New|   Status:  new
  feature|Component:  contrib.localflavor
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Ready for  |  Needs tests:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 All looks good, thank you!

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

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

Re: [Django] #15705: Localflavor for Croatia

[Django]

#15705: Localflavor for Croatia
---+---
   Reporter:  zmasek   |Owner:  zmasek
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  localflavor croatia
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+---

Comment (by julien):

 You might also consider putting your tests in
 source:django/trunk/tests/regressiontests/forms/localflavor
 Where ever it seems most logical to you.

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

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

Re: [Django] #11531: Remove unused file django/contrib/admin/media/js/dateparse.js

[Django]

#11531: Remove unused file django/contrib/admin/media/js/dateparse.js
-+-
   Reporter:  mk |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  contrib.admin
  Milestone: | Severity:  Normal
Version:  1.0| Keywords:
 Resolution: |Has patch:  0
   Triage Stage:  Ready for  |  Needs tests:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Agreed, there's no point in keeping this file -- it's not used anywhere.

 Marking RFC. There's no patch, simply delete the file
 `django/contrib/admin/media/js/dateparse.js`

-- 
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] #11460: Admin changelist shows no rows with a non-zero count where ForeignKeys are used in list_display and data is bad

[Django]

#11460: Admin changelist shows no rows with a non-zero count where ForeignKeys 
are
used in list_display and data is bad
+-
   Reporter:  afitzpatrick  |Owner:  nobody
   Type:  Bug   |   Status:  reopened
  Milestone:|Component:  Documentation
Version:  1.0   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * component:  contrib.admin => Documentation
 * stage:  Design decision needed => Accepted


Comment:

 The admin's codebase is already large and complicated enough taking care
 of all normal business that I think we shouldn't add more code taking care
 of problems that are out of the admin's control in the first place. We've
 got to draw the line somewhere.

 I think the right approach is, like it's been suggested, to improve the
 documentation -- maybe by adding a "Troubleshoot" section which could grow
 over time when new problems of this kind pop up in the future.

-- 
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] #10353: prompt the correct date/time format in the error message

[Django]

#10353: prompt the correct date/time format in the error message
---+--
   Reporter:  dryice   |Owner:  nobody
   Type:  New feature  |   Status:  closed
  Milestone:   |Component:  Forms
Version:  1.0  | Severity:  Normal
 Resolution:  wontfix  | Keywords:  date time datetime
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--

Comment (by dryice):

 "the assumption that the field needs to be entered in a specific format"
 is not coded in this patch, it's already in the code for
 DateField/TimeField/DateTimeField

 However I saw another reason why the patch should not be applied: Because
 the format check in the existing code has been i18n-ed, and checking all
 the formats.py in django/conf/locale/xx, there's no a universal format. So
 specifying the -MM-DD format in the error message may confuse some
 users don't use this format.

-- 
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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
   Reporter:  danbrwn|Owner:  mitsuhiko
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  foreign,key,quoted
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by camilonova):

 * version:  1.2 => 1.3


-- 
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] #15782: Runserver/runfcgi/startup with MySQL is unlike any other database

[Django]

#15782: Runserver/runfcgi/startup with MySQL is unlike any other database
---+-
 Reporter:  toofishes  | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  Database layer (models, ORM)
  Version:  1.3|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+-
 Django provides a BaseDatabaseValidation class. The only database engine
 to subclass this is MySQL.

 To reproduce:

 {{{
 $ django-admin.py foobar
 $ cd foobar
 
 $ python2 manage.py runserver
 Validating models...

 Unhandled exception in thread started by >
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 88, in
 inner_run
 self.validate(display_num_errors=True)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 249, in validate
 num_errors = get_validation_errors(s, app)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/validation.py", line 103, in
 get_validation_errors
 connection.validation.validate_field(e, opts, f)
   File "/usr/lib/python2.7/site-
 packages/django/db/backends/mysql/validation.py", line 14, in
 validate_field
 db_version = self.connection.get_server_version()
   File "/usr/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 338, in
 get_server_version
 self.cursor()
   File "/usr/lib/python2.7/site-packages/django/db/backends/__init__.py",
 line 250, in cursor
 cursor = self.make_debug_cursor(self._cursor())
   File "/usr/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 322, in _cursor
 self.connection = Database.connect(**kwargs)
   File "/usr/lib/python2.7/site-packages/MySQLdb/__init__.py", line 81, in
 Connect
 return Connection(*args, **kwargs)
   File "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line
 187, in __init__
 super(Connection, self).__init__(*args, **kwargs2)
 _mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL
 server through socket '/var/run/mysqld/mysqld.sock' (2)")
 }}}


 Expected result:

 {{{
 $ django-admin.py foobar
 $ cd foobar
 
 $ python2 manage.py runserver
 Validating models...

 0 errors found
 Django version 1.3, using settings 'foobar.settings'
 Development server is running at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 }}}

 Why this is a problem:
 1. The number one reason this is bad- no other database engine completely
 halts the Django project load if it is not up. It simply cannot service
 requests at all. All other database engines at least show a helpful 500
 page on each failed request.
 2. Validation like this doesn't come early enough for someone that
 develops on one database engine and then switches to MySQL.
 3. The validation that needs a valid connection is testing an extreme edge
 case- those using versions before 5.0.3. From http://www.mysql.com/support
 /eol-notice.html, Extended Support for 4.1 and Active Support for 5.0
 ended ended 2009-12-31.
 4. We are likely missing validation cases for other databases; we should
 be consistent in trying to do it right or not do it at all.
 5. The validation here isn't even correct for unique fields. max_length
 can be greater than 255, in reality the unique indexes are constrained to
 1000 bytes. For that matter, this also does nothing to keep one from
 shooting themselves in the foot with a combo unique index produced by
 unique_together.

 Potential fixes:
 1. Drop this database field validation completely, as only one database is
 even providing it and not even fully checking.
 2. Remove the bits referencing the connection; this will solve the most
 severe problem and those using old database versions should be well aware
 of the restrictions.
 3. Make the validation module do the right thing more often, fixing MySQL
 and adding it for other databases.

 I'd be happy to provide a patch for #1 or #2, but wanted some feedback
 first.

 Tangentially related to #7040.

-- 
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] #15781: Multiple databases with same model names causing get errors

[Django]

#15781: Multiple databases with same model names causing get errors
---+--
 Reporter:  anonymous  | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  Uncategorized
  Version:  1.2|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+--
 Code that causes the problem:

 everyone.py:
 class Person(models.Model):
  emplid = models.CharField(max_length=15,primary_key=True)
  ... (other fields deleted)

 class Meta:
 app_label = u'everyone'
 db_tablespace = u'everyone'
 db_table = u'people_names'
 managed = False

 people.py:
 class Person(models.Model):
  emplid = models.CharField(max_length=11, db_column='emplid',
 primary_key=True
 ) ... (other fields deleted)

 class Meta:
 app_label = u'commons'
 db_tablespace = u'people'
 db_table = u'person'

 The 2nd people.Person model is my default db, so #1 is "everyone.Person"
 and #2 is just "Person".

 I tried (view.py):

 try:
 person = everyone.Person.objects.get(pk=emplid)
 except everyone.Person.DoesNotExist: # person not found by "get"
 do some stuff

 django complains in the 'except' : global name 'everyone' is not defined.

 Apparently django does not support multi-database models in the same way
 as the default database. There is a work-around, but this behaviour then
 is inconsistent with default database models. Don't know if this is due to
 model names being the same.

-- 
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] #15771: "from django.contrib.auth.admin import UserAdmin" breaks backwards relations for User

[Django]

#15771: "from django.contrib.auth.admin import UserAdmin" breaks backwards
relations for User
---+
   Reporter:  morgan.harris@…  |Owner:  nobody
   Type:  Bug  |   Status:  closed
  Milestone:   |Component:  contrib.auth
Version:  1.3  | Severity:  Normal
 Resolution:  wontfix  | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+

Comment (by julien):

 Thanks for this info. I agree that it'd be nice to solve this bug, which
 #11448 appears to be addressing at the root. In the particular instance
 here, my point was that in order to work the admin has to do some pretty
 convoluted imports, leading to some inevitable limitations. For example,
 the recommended place to do `autodiscover()` is in the main `urls.py`
 because it is assumed that by the time that module gets loaded all models
 have already been imported. So the admin already does prevent some things
 that you may like to do, and if those things aren't best practice, then
 it's something that we can live with. But yeah, we should fix this bug if
 we can (via #11448).

-- 
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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  aaron.l.madison@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3| Severity:  Release blocker
 Resolution: | Keywords:  db mysql delete
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by aaron.l.madison@…):

 That patch seems to shift the problem. Now it blows up deleting item first
 when it hadn't already deleted the related item rate code. The integrity
 issues are not present on sqlite3... I'm not sure about postgres.

 {{{

 IntegrityError: (1451, 'Cannot delete or update a parent row: a foreign
 key constraint fails (`test_delete_test`.`myapp_itemratecode`, CONSTRAINT
 `item_id_refs_id_3db45024` FOREIGN KEY (`item_id`) REFERENCES `myapp_item`
 (`id`))')

 }}}

-- 
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] #15780: Broken link in release notes - csrf upgrade notes

[Django]

#15780: Broken link in release notes - csrf upgrade notes
---+--
 Reporter:  Aryeh Leib Taurog   | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  Documentation
  Version:  SVN|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+--
 When I build docs from svn trunk, I get the following errors:

 /tmp/build_django_docs/trunk/docs/releases/1.2.txt:436: WARNING: undefined
 label: ref-csrf-upgrading-notes  \\
 /tmp/build_django_docs/trunk/docs/releases/1.2.txt:863: WARNING: undefined
 label: ref-csrf-upgrading-notes \\
 /tmp/build_django_docs/trunk/docs/releases/1.2-alpha-1.txt:33: WARNING:
 undefined label: ref-csrf-upgrading-notes \\
 /tmp/build_django_docs/trunk/docs/releases/1.2-alpha-1.txt:198: WARNING:
 undefined label: ref-csrf-upgrading-notes

 The missing section label ref-csrf-upgrading-notes was removed in
 changeset:15949 from `trunk/docs/ref/contrib/csrf.txt`.

 The text for the link refers to UPGRADE INSTRUCTIONS.

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

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

Re: [Django] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  aaron.l.madison@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3| Severity:  Release blocker
 Resolution: | Keywords:  db mysql delete
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by emulbreh):

 It looks as if the fix is that simple. But I haven't checked for
 sideeffects yet, and in particular not with 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] #15721: {% include %} and RequestContext fails since r15795

[Django]

#15721: {% include %} and RequestContext fails since r15795
+---
   Reporter:  mk|Owner:  SmileyChris
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Template system
Version:  1.3   | Severity:  Release blocker
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by mvt):

 * cc: mvt (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] #11559: urlresolvers.reverse do not work with namespaced urls and captured parameters in parent urlconf

[Django]

#11559: urlresolvers.reverse do not work with namespaced urls and captured
parameters in parent urlconf
-+
   Reporter:  kmike84@…  |Owner:  nobody
   Type:  New feature|   Status:  new
  Milestone: |Component:  Core (Other)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Someday/Maybe  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by mvt):

 * cc: mvt (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] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

[Django]

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
-+-
   Reporter:  olau   |Owner:  nobody
   Type: |   Status:  new
  Uncategorized  |Component:  Core (Management
  Milestone: |  commands)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by gordl):

 * cc: gordl (added)
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 And, what's worse is that when populating the settings via the command
 line, the overridden settings are never loaded.  If I have a custom set of
 settings for certain management commands
 {{{
 manage.py mymanagementcommand --settings=custom_settings
 }}}
 The settings specified are not loaded.

-- 
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] #13206: Model does not call super __init__

[Django]

#13206: Model does not call super __init__
-+-
   Reporter:  gav|Owner:  nobody
   Type:  Bug|   Status:  closed
  Milestone:  1.3|Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution:  fixed  | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  __init__ super Model
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by mitar):

 * cc: mmitar@… (added)


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

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

[Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh | Owner:  nobody
     |Status:  new
 Type:  Bug  | Component:
Milestone:   |  contrib.admin
  Version:  1.3  |  Severity:  Normal
 Keywords:   |  Triage Stage:
Has patch:  0|  Unreviewed
-+-
 '''Problem'''
  If you have a model with a primary key field that has the value 'add' you
 won't be able to edit it in the admin screens. the admin will take you to
 the add page instead of the change page for that record. this is a problem
 with the design of the urls in the admin module. Example code follows:


 '''admin.py'''



 {{{
 from polls.models import poll
 from django.contrib import admin

 admin.site.register(poll)
 }}}


 '''model.py'''


 {{{
 from django.db import models

 class poll(models.Model):
id = models.CharField(max_length=200, primary_key=True)
question = models.CharField(max_length=200)

 }}}


 '''Reproducing'''


  1. Create project and app, enable admin, add the above files and syncdb.
  2. Go to the admin interface and select Add poll
  3. specify 'add' as the id and 'test' as question
  4. Save
  5. Go back to the list
  6. Open the same object
  7. you will be taken to the add poll screen instead of the change poll
 screen for the selected object

-- 
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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  aaron.l.madison@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3| Severity:  Release blocker
 Resolution: | Keywords:  db mysql delete
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by aaron.l.madison@…):

 I put some print statements in the django.db.models.deletion.py in the
 Collector.delete method where it does
 {{{
 # delete instances
 for model, instances in self.data.iteritems():
 query = sql.DeleteQuery(model)
 pk_list = [obj.pk for obj in instances]
 print "Deleting:", model, pk_list
 #query.delete_batch(pk_list, self.using)
 }}}

 The output is:

 {{{
 (delete_bug)amadison@dev-aaron:~/projects/delete_bug/project$ ./manage.py
 test myapp
 Creating test database for alias 'default'...
 Deleting:  [1L]
 Deleting:  [1L]
 Deleting:  [1L]
 Deleting:  [2L, 1L]
 Deleting:  [2L, 1L]
 Deleting:  [2L, 1L]
 Deleting:  [2L, 1L]

 }}}

 the SQL error is happening (i am fairly sure) because the version is
 trying to be deleted before the Item.

-- 
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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  aaron.l.madison@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3| Severity:  Release blocker
 Resolution: | Keywords:  db mysql delete
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jacob):

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


Comment:

 From the django-users thread, here's the failure message:

 {{{

 (delete_bug)amadison@dev-aaron:~/projects/delete_bug/project$ ./manage.py
 test myapp
 Creating test database for alias 'default'...
 E
 ==
 ERROR: test_deletes_policy_successfully (myapp.tests.DeletePolicyTests)
 --
 Traceback (most recent call last):
   File "/home/amadison/projects/delete_bug/project/myapp/tests.py", line
 34, in test_deletes_policy_successfully
 self.assertEqual(None, policy.delete())
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/base.py", line 581, in delete
 collector.delete()
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/deletion.py", line 63, in decorated
 func(self, *args, **kwargs)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/deletion.py", line 254, in delete
 query.delete_batch(pk_list, self.using)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/sql/subqueries.py", line 44, in delete_batch
 self.do_query(self.model._meta.db_table, where, using=using)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/sql/subqueries.py", line 29, in do_query
 self.get_compiler(using).execute_sql(None)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/django/db/backends/mysql/base.py", line 86, in execute
 return self.cursor.execute(query, args)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/MySQLdb/cursors.py", line 174, in execute
 self.errorhandler(self, exc, value)
   File "/home/amadison/projects/delete_bug/lib/python2.6/site-
 packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
 raise errorclass, errorvalue
 IntegrityError: (1451, 'Cannot delete or update a parent row: a foreign
 key constraint fails (`test_delete_test`.`myapp_item`, CONSTRAINT
 `version_id_refs_id_15106961` FOREIGN KEY (`version_id`) REFERENCES
 `myapp_version` (`id`))')

 --
 Ran 1 test in 0.120s
 }}}

-- 
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] #15778: Command createsuperuser fails under some system user names

[Django]

#15778: Command createsuperuser fails under some system user names
-+-
 Reporter:  Hynek Cernoch   | Owner:  nobody
 Type:  Bug  |Status:  new
Milestone:  1.3  | Component:  contrib.auth
  Version:  1.3  |  Severity:  Normal
 Keywords:   |  Triage Stage:  Unreviewed
Has patch:  1|
-+-
 Commands 'createsuperuser' and 'syncdb' can not create a superuser account
 no way because of database error,
 if a system account username contains an 8-bit character.
 It fails when the name is automatically searched in the database, even if
 the user wants to write an ascii username manually.
 This is typical for usernames created by Microsoft Windows.

 {{{
 File "C:\Python26\lib\site-
 packages\django\contrib\auth\management\commands\createsuperuser.py", line
 72, in handle
   User.objects.get(username=default_username)
 ...
 File "C:\Python26\lib\site-packages\django\db\backends\sqlite3\base.py",
 line 234, in execute
   return Database.Cursor.execute(self, query, params)
 DatabaseError : You must not use 8-bit bytestrings unless you use a
 text_factory that can interpret
 8-bit bytestrings (like text_factory = str). It is highly recommended that
 you instead just switch
 your application to Unicode strings.
 }}}


 Versions: Django 1.3, Python 2.6.4 windows, Sqlite3 3.5.9, dbapi 2.4.1

 It is easier to fix it once then to circumvent it twice.

 The middle part of the patch:
 {{{
 -default_username = getpass.getuser().replace(' ', '').lower()
 +default_username = str(getpass.getuser().decode('ascii',
 'ignore')).replace(' ', '').lower()
 }}}

-- 
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] #15777: Broken "mtv" reference in 1.2.X glossary

[Django]

#15777: Broken "mtv" reference in 1.2.X glossary
---+--
 Reporter:  Aryeh Leib Taurog   | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  Documentation
  Version:  1.2|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+--
 I get the following errors when I build the docs in the 1.2.X branch:

 /tmp/download/dj-1.2.5/docs/glossary.txt:27: WARNING: undefined label: mtv
 (if the link has no caption the label must precede a section header) \\
 /tmp/download/dj-1.2.5/docs/glossary.txt:30: WARNING: undefined label: mtv
 (if the link has no caption the label must precede a section header)

 This can be fixed using the changes to the following files from
 changeset:15893:

 {{{
 trunk/docs/faq/general.txt
 trunk/docs/glossary.txt
 }}}

-- 
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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
 Reporter:   | Owner:  nobody
  aaron.l.madison@…  |Status:  new
 Type:  Bug  | Component:  Database layer (models, ORM)
Milestone:  1.3  |  Severity:  Release blocker
  Version:  1.3  |  Triage Stage:  Unreviewed
 Keywords:  db mysql delete  |
Has patch:  0|
-+-
 I have found a bug the way Django 1.3 carries out its cascade delete using
 MySQL. (the operation works fine in django 1.2.5)

 Here is a stripped example from our production data.

 {{{
 from django.db import models

 class Policy(models.Model):
 policy_number = models.CharField(max_length=10)

 class Version(models.Model):
 policy = models.ForeignKey(Policy)

 class Location(models.Model):
 version = models.ForeignKey(Version, blank=True, null=True)

 class Item(models.Model):
 version = models.ForeignKey(Version)
 location = models.ForeignKey(Location, blank=True, null=True)

 class ItemRateCode(models.Model):
 item = models.ForeignKey(Item)

 class PropertyItem(models.Model):
 item_rate_code = models.ForeignKey(ItemRateCode)

 class Coverage(models.Model):
 version = models.ForeignKey(Version)
 item_rate_code = models.ForeignKey(ItemRateCode)
 }}}

 After you syncdb, execute the following to load the data and try to delete
 the policy:

 {{{
 from myapp.models import Policy, Version, Location, Item
 from myapp.models import ItemRateCode, PropertyItem, Coverage

 policy = Policy.objects.create(pk=1, policy_number="1234")
 version = Version.objects.create(policy=policy)
 location = Location.objects.create(version=version)

 item1 = Item.objects.create(version=version, location=location)
 item2 = Item.objects.create(version=version, location=location)

 # one for each item
 item_rate_code1 = ItemRateCode.objects.create(item=item1)
 item_rate_code2 = ItemRateCode.objects.create(item=item2)

 # one for each item_rate_code
 coverage1 = Coverage.objects.create(version=version,
 item_rate_code=item_rate_code1)
 coverage2 = Coverage.objects.create(version=version,
 item_rate_code=item_rate_code2)

 # one for each item_rate_code
 property_item1 =
 PropertyItem.objects.create(item_rate_code=item_rate_code1)
 property_item2 =
 PropertyItem.objects.create(item_rate_code=item_rate_code2)

 policy = Policy.objects.get(pk=1)
 policy.delete()
 }}}

 (I have included a sample project with a failing/blowing up testcase...
 the test passes on 1.2.5)

 For some reason, the delete collector I believe is trying to delete the
 "Version" before it has deleted the "Item"s

-- 
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] #15775: Can't enter scientific notation in decimal fields

[Django]

#15775: Can't enter scientific notation in decimal fields
---+--
 Reporter:  gregthe1   | Owner:  nobody
 Type:  Uncategorized  |Status:  new
Milestone: | Component:  Uncategorized
  Version:  1.2|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+--
 Here is an example:

 {{{

 >>> from django.forms import DecimalField
 >>> f = DecimalField(max_digits=10, decimal_places=1)
 >>> f.validate(Decimal('1E+2'))
 Traceback (most recent call last):
 ...
 ValidationError: [u'Ensure that there are no more than 1 decimal places.']
 }}}


 Also if I try upping the max_digits and decimal_places to something like
 20, and 13, I get this error:


 {{{
 quantize result has too many digits for current context
 }}}

-- 
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] #3860: AttributeError: 'module' object has no attribute 'myapp'

[Django]

#3860: AttributeError: 'module' object has no attribute 'myapp'
-+
   Reporter:  Vinay Sajip|Owner:  adrian
   Type:  Uncategorized  |   Status:  closed
  Milestone: |Component:  Contrib apps
Version:  SVN| Severity:  Normal
 Resolution:  invalid| Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by eternicode):

 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 Sorry to comment on a 4-year-old thread, but this is the first google
 result for this issue, no apparent resolution was reached here, and the
 django-users discussion (if there was one) is not linked :)

 The problem is that {{{myapp/__init__.py}}} imports {{{auth.models}}} when
 it's executed; at this point, the subpackage {{{myapp}}} of {{{mysite}}}
 has not yet been imported, and is not yet an attribute on the parent
 package ({{{mysite.myapp}}} doesn't exist yet).  {{{auth.models}}},
 though, imports and invokes the translation framework, which in turn tries
 to import each of {{{INSTALLED_APPS}}} by importing the app's parent
 package ({{{django.contrib}}} or {{{mysite}}}) and doing a {{{getattr}}}
 for the app package -- ie, effectively {{{getattr(mysite, 'myapp')}}}.
 It's some kind of circular dependency breakdown.

 The solution is 1) not import things that use the translation framework
 from an app's {{{__init__.py}}} or 2) delay the import until after all
 apps have been imported.

-- 
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] #15774: UnicodeDecodeError with makemessages

[Django]

#15774: UnicodeDecodeError with makemessages
--+-
 Reporter:  deschler  | Owner:  nobody
 Type:  Bug   |Status:  new
Milestone:| Component:  Internationalization
  Version:  1.3   |  Severity:  Normal
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+-
 Running makemessages in the project folder throws a UnicodeDecodeError
 here with django-1.3. Everything works fine with django-1.2.

 {{{
 $ ./manage.py makemessages -l de
 processing language de
 Traceback (most recent call last):
   File "./manage.py", line 11, in 
 execute_manager(settings)
   File "/path/to/django/core/management/__init__.py", line 438, in
 execute_manager
 utility.execute()
   File "/path/to/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/path/to/django/core/management/base.py", line 191, in
 run_from_argv
 self.execute(*args, **options.__dict__)
   File "/path/to/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/path/to/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/path/to/django/core/management/commands/makemessages.py", line
 365, in handle_noargs
 make_messages(locale, domain, verbosity, process_all, extensions,
 symlinks, ignore_patterns, no_wrap, no_obsolete)
   File "/path/to/django/core/management/commands/makemessages.py", line
 233, in make_messages
 f.write(templatize(src, orig_file[2:]))
   File "/path/to/django/utils/translation/__init__.py", line 127, in
 templatize
 return _trans.templatize(src, origin)
   File "/path/to/django/utils/translation/trans_real.py", line 450, in
 templatize
 content = u''.join(comment)
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 284:
 ordinal not in range(128)
 }}}

 Is this in any way related to the changes made in project level
 translation handling mentioned in the 1.3 release notes? I'm not sure if i
 understand them correctly, does it mean that project level should be
 avoided in favour of app level translations in general? Adding the project
 locale folder to LOCALE_PATHS doesn't make a difference by the way, same
 UnicodeDecodeError.

-- 
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] #12446: multipart/mixed in multipart/form-data

[Django]

#12446: multipart/mixed in multipart/form-data
-+-
   Reporter: |Owner:
     |   Status:  new
   Type:  New|Component:  File uploads/storage
  feature| Severity:  Normal
  Milestone: | Keywords:  multipart/mixed
Version:  1.1|Has patch:  0
 Resolution: |  Needs tests:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by tomchristie):

 * cc: tomchristie (added)


Comment:

 Okay, so according to the spec, yes "multipart/mixed" is defiantly
 required.

   '''RFC 2388 - Returning Values from Forms: multipart/form-data'''

   http://www.faqs.org/rfcs/rfc2388.html

   'If multiple files are to be returned as
   the result of a single form entry, they should be represented as a
   "multipart/mixed" part embedded within the "multipart/form-data".'

   '''W3C HTML 4.01 spec'''

   http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2

   'If multiple files are to be returned as the result of a single form
 entry, they should be returned as "multipart/mixed" embedded within the
 "multipart/form-data".'

   '''W3C HTML 5 spec'''

   http://www.w3.org/TR/html5/association-of-controls-and-forms.html
 #multipart-form-data

   'Encode the (now mutated) form data set using the rules described by RFC
 2388, Returning Values from Forms: multipart/form-data, and return the
 resulting byte stream.'

 However, it appears that firefox, safari and chrome disregard this and
 simply return a flat list of files inside the "multipart/form-data"
 wrapper, and only opera conforms to the spec and returns a
 "multipart/mixed" wrapped inside the "multipart/form-data".

 I've attached the files output from an upload of two simple text files in
 each case for future reference of anyone looking into this ticket.

 So it looks like this Django currently handles multiple file uploads from
 firefox/safari/chrome just fine, but fails for opera (and fails according
 to the specs as they stand).

 [attaching chrome-10.0.txt, firefox-4.0.txt, safari-5.0.txt,
 opera-11.0.txt]

-- 
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] #15773: MultiValueField could be more convenient

[Django]

#15773: MultiValueField could be more convenient
---+---
 Reporter:  Aryeh Leib Taurog   | Owner:  nobody
 Type:  New feature|Status:  new
Milestone: | Component:  Forms
  Version:  1.3|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 It seems to me that the !MultiValueField could be a lot more useful.  I'm
 assuming the !SplitDateTimeField code exemplifies the normal use case, and
 I see two things here that bother me.

 1. To use !MultiValueField, coder '''must''' create and assign a widget
 class.  Maybe I'm just lazy because the other Field classes seem to
 provide reasonable defaults, but couldn't this field provide a reasonable
 default as well?

 2. `compress` must be defined on the Field class, but `decompress` must be
 defined on the Widget class.  I don't know if I'd call this a violation of
 DRY, but it seems to me it  would be much nicer to put these two together,
 since one is the inverse of the other.  Obviously there's nothing
 preventing me from putting my !MultiWidget subclass and !MultiValueField
 subclass together, but if I separate the Widgets from the Fields, as the
 django source has done, then I introduce room for maintenance errors.

 I guess this is mainly about convenience.  We '''do''' like making good
 development practice more convenient.

 My suggestion for addressing these two points is below.  Thanks for
 reading.

 {{{#!python
 from django.forms import fields
 from django.forms import widgets

 class MultiValueFieldWidgetDescriptor(object):
 def __get__(self, instance, owner):
 widget_base = getattr(owner, 'widget_base', widgets.MultiWidget)
 class MyWidget(widget_base):
 def __init__(self, attrs=None):
 widgets = [f.widget for f in instance.fields]
 super(MyWidget, self).__init__(widgets, attrs)

 decompress = owner.decompress.__get__(self)

 return MyWidget

 class MultiValueField(fields.MultiValueField):
 widget = MultiValueFieldWidgetDescriptor()
 }}}

-- 
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] #11448: Defining relationships after querying a model does not add a reverse lookup to the referenced model

[Django]

#11448: Defining relationships after querying a model does not add a reverse 
lookup
to the referenced model
-+-
   Reporter:  Dennis |Owner:  nobody
  Kaarsemaker|   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by kmtracey):

 #15771 looks like another case of this error, now triggered by importing
 from `contrib.auth.admin` before defining a model with a relationship to
 User -- something that used (1.2.X) to work. Not sure what has changed
 that it now (1.3) triggers this error.

-- 
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] #15771: "from django.contrib.auth.admin import UserAdmin" breaks backwards relations for User

[Django]

#15771: "from django.contrib.auth.admin import UserAdmin" breaks backwards
relations for User
---+
   Reporter:  morgan.harris@…  |Owner:  nobody
   Type:  Bug  |   Status:  closed
  Milestone:   |Component:  contrib.auth
Version:  1.3  | Severity:  Normal
 Resolution:  wontfix  | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+

Comment (by anonymous):

 The underlying problem here is likely the same as #11247/#11448, it has
 been around for a long time. Possibly something has changed in the
 contrib.auth code to trigger it now where it wasn't triggered in the past.
 While it is true that intermixing model and admin definitions is generally
 bad practice, getting the underlying bug fixed would be a good idea. It's
 not particularly nice that a harmless-looking sequence of imports (even if
 they are not best practice) would cause this kind of side-effect.

-- 
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] #15698: Inconsistant handling of context_object_name in paginated MultipleObjectMixin

[Django]

#15698: Inconsistant handling of context_object_name in paginated
MultipleObjectMixin
+-
   Reporter:  etianen   |Owner:  etianen
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Generic views
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+-
Changes (by etianen):

 * needs_tests:  1 => 0


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

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

Re: [Django] #7005: add orphans support for object_list pagination

[Django]

#7005: add orphans support for object_list pagination
-+-
   Reporter:  shadfc |Owner:  shadfc
   Type:  New|   Status:  assigned
  feature|Component:  Generic views
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  orphans object_list
 Resolution: |  paginator
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  1  |
-+-
Changes (by Dzhus):

 * cc: dima@… (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] #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: |Owner:  nobody
  david_heagney  |   Status:  reopened
   Type: |Component:  Database layer
  Uncategorized  |  (models, ORM)
  Milestone:  1.3| Severity:  Normal
Version:  1.3| Keywords:  syncdb mysql
 Resolution: |Has patch:  1
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by pawel.krzyzaniak@…):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  worksforme =>
 * version:  1.2 => 1.3
 * has_patch:  0 => 1
 * type:   => Uncategorized


Comment:

 I had the same problem - it is caused by non-ascii characters in the
 Windows username (in my case the username is Paweł).

 quick fix (just ignoring the non-ascii character):
   contrib\auth\management\commands\createsuperuser.py, line 61:[[br]]
   ++default_username = getpass.getuser().replace(' ',
 '').decode('ascii','ignore').lower()[[br]]
   --default_username = getpass.getuser().replace(' ', '').lower()

-- 
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] r16021 - django/trunk/django/contrib/gis/db/backends/mysql

[noreply]

Author: ramiro
Date: 2011-04-06 04:19:37 -0700 (Wed, 06 Apr 2011)
New Revision: 16021

Modified:
   django/trunk/django/contrib/gis/db/backends/mysql/base.py
Log:
Fixed #15772 -- Corrected an oversight from r16016 in MySQL GeoDjango DB 
backend. Thanks JannKleen for the report and patch.

Modified: django/trunk/django/contrib/gis/db/backends/mysql/base.py
===
--- django/trunk/django/contrib/gis/db/backends/mysql/base.py   2011-04-06 
10:33:32 UTC (rev 16020)
+++ django/trunk/django/contrib/gis/db/backends/mysql/base.py   2011-04-06 
11:19:37 UTC (rev 16021)
@@ -9,5 +9,5 @@
 def __init__(self, *args, **kwargs):
 super(DatabaseWrapper, self).__init__(*args, **kwargs)
 self.creation = MySQLCreation(self)
-self.ops = MySQLOperations()
+self.ops = MySQLOperations(self)
 self.introspection = MySQLIntrospection(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] #15772: geodjango mysql connection wrapper not working

[Django]

#15772: geodjango mysql connection wrapper not working
-+-
   Reporter:  JannKleen  |Owner:  ramiro
   Type:  Bug|   Status:  new
  Milestone: |Component:  GIS
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:  database, MySQL
   Triage Stage:  Ready for  |Has patch:  1
  checkin|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by ramiro):

 * owner:  JannKleen => ramiro
 * status:  assigned => new
 * version:  1.3-rc1 => SVN
 * milestone:  1.3 =>


-- 
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] #15772: geodjango mysql connection wrapper not working

[Django]

#15772: geodjango mysql connection wrapper not working
-+-
   Reporter:  JannKleen  |Owner:  JannKleen
   Type:  Bug|   Status:  assigned
  Milestone:  1.3|Component:  GIS
Version:  1.3-rc1| Severity:  Normal
 Resolution: | Keywords:  database, MySQL
   Triage Stage:  Ready for  |Has patch:  1
  checkin|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by JannKleen):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #15772: geodjango mysql connection wrapper not working

[Django]

#15772: geodjango mysql connection wrapper not working
-+---
 Reporter:  JannKleen| Owner:  JannKleen
 Type:  Bug  |Status:  new
Milestone:  1.3  | Component:  GIS
  Version:  1.3-rc1  |  Severity:  Normal
 Keywords:  database, MySQL  |  Triage Stage:  Unreviewed
Has patch:  1|
-+---
 applied changes made in [16016] to GIS-mysql wrapper as well

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

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

Re: [Django] #15698: Inconsistant handling of context_object_name in paginated MultipleObjectMixin

[Django]

#15698: Inconsistant handling of context_object_name in paginated
MultipleObjectMixin
+-
   Reporter:  etianen   |Owner:  etianen
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Generic views
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+-
Changes (by etianen):

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


Comment:

 I'll add in a test to my patch today. Watch this space. :)

-- 
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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+
   Reporter:  etianen|Owner:  nobody
   Type:  Uncategorized  |   Status:  new
  Milestone:  1.3|Component:  contrib.auth
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by etianen):

 * cc: etianen (added)
 * type:   => Uncategorized
 * severity:   => Normal


-- 
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] #9422: Incorrect handling of foreign keys by serializers

[Django]

#9422: Incorrect handling of foreign keys by serializers
-+-
   Reporter:  etianen|Owner:
   Type: |   Status:  new
  Uncategorized  |Component:  Core (Serialization)
  Milestone: | Severity:  Normal
Version:  1.0| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by etianen):

 * cc: etianen (added)
 * type:   => Uncategorized
 * severity:   => Normal


-- 
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] #15694: Overriding Django admin views and nested transactions

[Django]

#15694: Overriding Django admin views and nested transactions
-+-
   Reporter:  etianen|Owner:  nobody
   Type: |   Status:  new
  Uncategorized  |Component:  contrib.admin
  Milestone: | Severity:  Normal
Version:  1.2| Keywords:
 Resolution: |Has patch:  0
   Triage Stage:  Design |  Needs tests:  1
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by etianen):

 * cc: etianen (added)
 * type:   => Uncategorized


Comment:

 I'm very happy to write the tests, documentation and the like. Once (if)
 this gets accepted, I'll get right on it.

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

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

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

[noreply]

Author: SmileyChris
Date: 2011-04-06 03:33:32 -0700 (Wed, 06 Apr 2011)
New Revision: 16020

Modified:
   django/trunk/docs/ref/models/fields.txt
Log:
Fixes #10786 -- Document that NullBooleanField should be used rather than 
BooleanField with null=True. Thanks sbj3 for the patch.

Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2011-04-06 10:12:21 UTC (rev 
16019)
+++ django/trunk/docs/ref/models/fields.txt 2011-04-06 10:33:32 UTC (rev 
16020)
@@ -59,6 +59,9 @@
 coerced for string-based fields that have the empty string as a possible
 value, and the value ``NULL`` will be stored to denote the empty string.
 
+If you want to accept :attr:`~Field.null` values with :class:`BooleanField`,
+use :class:`NullBooleanField` instead.
+
 ``blank``
 -
 
@@ -341,6 +344,9 @@
 
 The admin represents this as a checkbox.
 
+If you need to accept :attr:`~Field.null` values then use
+:class:`NullBooleanField` instead.
+
 .. versionchanged:: 1.2
 
 In previous versions of Django when running under MySQL ``BooleanFields``

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10786: Missing Documentation for new BooleanField limitation

[Django]

#10786: Missing Documentation for new BooleanField limitation
-+-
   Reporter: |Owner:  sbj3
  robingreen |   Status:  new
   Type: |Component:  Core (Other)
  Cleanup/optimization   | Severity:  Normal
  Milestone: | Keywords:
Version:  1.0|Has patch:  1
 Resolution: |  Needs tests:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
---+---
   Reporter:  mtredinnick  |Owner:  mtredinnick
   Type:  Bug  |   Status:  new
  Milestone:   |Component:  ORM aggregation
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+---
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10793: Sitemap implementation means it cannot be updated automatically

[Django]

#10793: Sitemap implementation means it cannot be updated automatically
+
   Reporter:  tenkujin  |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.sitemaps
Version:  1.0   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10797: Set up Trac so post-commit hook sends emails

[Django]

#10797: Set up Trac so post-commit hook sends emails
-+-
   Reporter:  carljm |Owner:  nobody
   Type:  Bug|   Status:  reopened
  Milestone: |Component:  Djangoproject.com Web
Version: |  site
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10762: Gzip Middleware Should Compress 201 (Created) Responses

[Django]

#10762: Gzip Middleware Should Compress 201 (Created) Responses
-+-
   Reporter:  rwagner@…  |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  HTTP handling
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  middleware gzip
 Resolution: |Has patch:  1
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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] #10706: Incorrect error from manage.py sql when app fails to load

[Django]

#10706: Incorrect error from manage.py sql when app fails to load
-+-
   Reporter:  Glenn  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Core (Management
Version:  SVN|  commands)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  1  |  Needs tests:  0
-+-
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10711: Add a hook for specifying whether a form in a formset should be deleted

[Django]

#10711: Add a hook for specifying whether a form in a formset should be deleted
-+-
   Reporter: |Owner:  jkocherhans
  bretthoerner   |   Status:  assigned
   Type:  New|Component:  Forms
  feature| Severity:  Normal
  Milestone: | Keywords:  admin forms formset
Version: |  deletion
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by SmileyChris):

 * type:   => New feature
 * severity:   => Normal


Comment:

 Hey Joseph, 1.3 is out! Fix this!

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

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

Re: [Django] #10720: OrderedManyToMany API Implementation

[Django]

#10720: OrderedManyToMany API Implementation
-+-
   Reporter:  Aryeh  |Owner:  nobody
  Leib Taurog |   Status:  new
   Type:  New|Component:  Database layer
  feature|  (models, ORM)
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  Ordered ManyToMany
 Resolution: |Has patch:  1
   Triage Stage:  Design |  Needs tests:  1
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * type:   => New feature
 * severity:   => Normal


-- 
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] #10725: Autoreloader hides signal exits from child

[Django]

#10725: Autoreloader hides signal exits from child
+
   Reporter:  Glenn |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Core (Other)
Version:  SVN   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10733: Invalid results when deferring fields in more than one related model with only()

[Django]

#10733: Invalid results when deferring fields in more than one related model 
with
only()
-+-
   Reporter:  mrts   |Owner:  nobody
   Type:  Bug|   Status:  reopened
  Milestone:  1.3|Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  efficient-admin
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  1  |  Needs tests:  0
-+-
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10739: MySQL and order_by()

[Django]

#10739: MySQL and order_by()
-+-
   Reporter:  stephaner  |Owner:  nobody
   Type:  Bug|   Status:  reopened
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10743: Support lookup separators in ModelAdmin.list_display

[Django]

#10743: Support lookup separators in ModelAdmin.list_display
-+-
   Reporter:  mrts   |Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  contrib.admin
  Milestone:  1.4| Severity:  Normal
Version:  SVN| Keywords:  efficient-admin,
 Resolution: |  list_display
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * type:   => New feature
 * severity:   => Normal


-- 
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] #10744: transaction.leave_transaction_management leaks

[Django]

#10744: transaction.leave_transaction_management leaks
-+-
   Reporter:  Glenn  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] r16019 - in django/trunk/docs: ref topics

[noreply]

Author: SmileyChris
Date: 2011-04-06 03:12:21 -0700 (Wed, 06 Apr 2011)
New Revision: 16019

Modified:
   django/trunk/docs/ref/signals.txt
   django/trunk/docs/topics/signals.txt
Log:
Fixes #10754 - minor clarification to the post/pre_delete signal documentation

Modified: django/trunk/docs/ref/signals.txt
===
--- django/trunk/docs/ref/signals.txt   2011-04-06 09:40:26 UTC (rev 16018)
+++ django/trunk/docs/ref/signals.txt   2011-04-06 10:12:21 UTC (rev 16019)
@@ -151,7 +151,7 @@
:module:
 
 Sent at the beginning of a model's :meth:`~django.db.models.Model.delete`
-method.
+method and a queryset's :meth:`~django.db.models.query.QuerySet.delete` method.
 
 Arguments sent with this signal:
 
@@ -172,8 +172,9 @@
 .. data:: django.db.models.signals.post_delete
:module:
 
-Like :data:`pre_delete`, but sent at the end of the
-:meth:`~django.db.models.Model.delete` method.
+Like :data:`pre_delete`, but sent at the end of a model's
+:meth:`~django.db.models.Model.delete` method and a queryset's
+:meth:`~django.db.models.query.QuerySet.delete` method.
 
 Arguments sent with this signal:
 

Modified: django/trunk/docs/topics/signals.txt
===
--- django/trunk/docs/topics/signals.txt2011-04-06 09:40:26 UTC (rev 
16018)
+++ django/trunk/docs/topics/signals.txt2011-04-06 10:12:21 UTC (rev 
16019)
@@ -25,6 +25,7 @@
   :data:`django.db.models.signals.post_delete`
 
   Sent before or after a model's :meth:`~django.db.models.Model.delete`
+  method or queryset's :meth:`~django.db.models.query.QuerySet.delete`
   method is called.
 
 * :data:`django.db.models.signals.m2m_changed`

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

[Django]

#10754: post and pre_delete signal documentation imprecise
-+-
   Reporter:  runeh  |Owner:  nobody
   Type: |   Status:  reopened
  Cleanup/optimization   |Component:  Documentation
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  signals
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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] #15725: No easy way to get default model values into a ModelForm for validation

[Django]

#15725: No easy way to get default model values into a ModelForm for validation
---+-
   Reporter:  mark0978 |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  Uncategorized
Version:  1.2  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-
Changes (by tomchristie):

 * cc: tomchristie (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] #10756: Correct PLNIPField

[Django]

#10756: Correct PLNIPField
+---
   Reporter:  remik |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.localflavor
Version:  1.0   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by SmileyChris):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #10761: ModelAdmin.queryset() is missing a mechanism for specifying different querysets for changelist and change object views

[Django]

#10761: ModelAdmin.queryset() is missing a mechanism for specifying different
querysets for changelist and change object views
---+---
   Reporter:  mrts |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  efficient-admin
   Triage Stage:  Accepted |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+---
Changes (by SmileyChris):

 * type:   => New feature
 * severity:   => Normal


-- 
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] r16018 - in django/trunk: django/core docs/topics tests/regressiontests/pagination_regress

[noreply]

Author: SmileyChris
Date: 2011-04-06 02:40:26 -0700 (Wed, 06 Apr 2011)
New Revision: 16018

Modified:
   django/trunk/django/core/paginator.py
   django/trunk/docs/topics/pagination.txt
   django/trunk/tests/regressiontests/pagination_regress/tests.py
Log:
Fixes #11596 -- Make paginator.Page iterable

Modified: django/trunk/django/core/paginator.py
===
--- django/trunk/django/core/paginator.py   2011-04-05 11:29:16 UTC (rev 
16017)
+++ django/trunk/django/core/paginator.py   2011-04-06 09:40:26 UTC (rev 
16018)
@@ -1,4 +1,5 @@
 from math import ceil
+import collections
 
 class InvalidPage(Exception):
 pass
@@ -84,6 +85,44 @@
 def __repr__(self):
 return '' % (self.number, self.paginator.num_pages)
 
+def __len__(self):
+return len(self.object_list)
+
+def __getitem__(self, index):
+# The object_list is converted to a list so that if it was a QuerySet
+# it won't be a database hit per __getitem__.
+return list(self.object_list)[index]
+
+# The following four methods are only necessary for Python <2.6
+# compatibility (this class could just extend 2.6's collections.Sequence).
+
+def __iter__(self):
+i = 0
+try:
+while True:
+v = self[i]
+yield v
+i += 1
+except IndexError:
+return
+
+def __contains__(self, value):
+for v in self:
+if v == value:
+return True
+return False
+
+def index(self, value):
+for i, v in enumerate(self):
+if v == value:
+return i
+raise ValueError
+
+def count(self, value):
+return sum([1 for v in self if v == value])
+
+# End of compatibility methods.
+
 def has_next(self):
 return self.number < self.paginator.num_pages
 

Modified: django/trunk/docs/topics/pagination.txt
===
--- django/trunk/docs/topics/pagination.txt 2011-04-05 11:29:16 UTC (rev 
16017)
+++ django/trunk/docs/topics/pagination.txt 2011-04-06 09:40:26 UTC (rev 
16018)
@@ -81,22 +81,20 @@
 
 The view function looks like this::
 
-from django.core.paginator import Paginator, InvalidPage, EmptyPage
+from django.core.paginator import Paginator, EmptyPage, PageNotAnInteger
 
 def listing(request):
 contact_list = Contacts.objects.all()
 paginator = Paginator(contact_list, 25) # Show 25 contacts per page
 
-# Make sure page request is an int. If not, deliver first page.
+page = request.GET.get('page')
 try:
-page = int(request.GET.get('page', '1'))
-except ValueError:
-page = 1
-
-# If page request () is out of range, deliver last page of results.
-try:
 contacts = paginator.page(page)
-except (EmptyPage, InvalidPage):
+except PageNotAnInteger:
+# If page is not an integer, deliver first page.
+contacts = paginator.page(1)
+except EmptyPage:
+# If page is out of range (e.g. ), deliver last page of 
results.
 contacts = paginator.page(paginator.num_pages)
 
 return render_to_response('list.html', {"contacts": contacts})
@@ -104,7 +102,7 @@
 In the template :file:`list.html`, you'll want to include navigation between
 pages along with any interesting information from the objects themselves::
 
-{% for contact in contacts.object_list %}
+{% for contact in contacts %}
 {# Each "contact" is a Contact model object. #}
 {{ contact.full_name|upper }}
 ...
@@ -126,7 +124,12 @@
 
 
 
+.. versionchanged:: 1.4
+Previously, you would need to use
+``{% for contact in contacts.object_list %}``, since the ``Page``
+object was not iterable.
 
+
 ``Paginator`` objects
 =
 
@@ -194,6 +197,7 @@
 
 A 1-based range of page numbers, e.g., ``[1, 2, 3, 4]``.
 
+
 ``InvalidPage`` exceptions
 ==
 
@@ -221,6 +225,9 @@
 You usually won't construct :class:`Pages ` by hand -- you'll get them
 using :meth:`Paginator.page`.
 
+.. versionadded:: 1.4
+A page acts like a sequence of :attr:`Page.object_list` when using
+``len()`` or iterating it directly.
 
 Methods
 ---

Modified: django/trunk/tests/regressiontests/pagination_regress/tests.py
===
--- django/trunk/tests/regressiontests/pagination_regress/tests.py  
2011-04-05 11:29:16 UTC (rev 16017)
+++ django/trunk/tests/regressiontests/pagination_regress/tests.py  
2011-04-06 09:40:26 UTC (rev 16018)
@@ -154,3 +154,15 @@
 self.assertRaises(EmptyPage, self.check_indexes, ([], 4, 0, False), 1, 
None)
 self.assertRaises(EmptyPage, self.check_indexes, ([], 4, 1, False), 1, 
None)
 

Re: [Django] #10532: An overridden get method on a custom manager passed to get_object_or_404 will not be called.

[Django]

#10532: An overridden get method on a custom manager passed to get_object_or_404
will not be called.
-+-
   Reporter:  anonymous  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Design | Keywords:
  decision needed|Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by SmileyChris):

 If there were any updates on the bug, you'd see them here.

 Since it sounds like you're already working with code to work around this
 issue, perhaps you'd care to produce a patch and test case? That's the
 kind of thing that gets things moving.

 At the very least, start a discussion on the django-dev mailing list.

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

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

Re: [Django] #10532: An overridden get method on a custom manager passed to get_object_or_404 will not be called.

[Django]

#10532: An overridden get method on a custom manager passed to get_object_or_404
will not be called.
-+-
   Reporter:  anonymous  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Design | Keywords:
  decision needed|Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by ccrisan):

 Any updates on this bug? So far the only resolution I've found is to use
 my own get_object_or_404() function.

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

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

Re: [Django] #15757: get_and_delete_messages, removed in [15975], is still alive

[Django]

#15757: get_and_delete_messages, removed in [15975], is still alive
+---
   Reporter:  void  |Owner:  nobody
   Type:  Bug   |   Status:  reopened
  Milestone:  1.4   |Component:  contrib.auth
Version:  SVN   | Severity:  Release blocker
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by julien):

 * has_patch:  0 => 1


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

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

Re: [Django] #15757: get_and_delete_messages, removed in [15975], is still alive

[Django]

#15757: get_and_delete_messages, removed in [15975], is still alive
+---
   Reporter:  void  |Owner:  nobody
   Type:  Bug   |   Status:  reopened
  Milestone:  1.4   |Component:  contrib.auth
Version:  SVN   | Severity:  Release blocker
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---

Comment (by julien):

 The attached patch cleans things up and also updates the doc to indicate
 the admin's dependency on `contrib.messages` and its middleware and
 context_processor.

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