Re: [Django] #15621: ImportError thrown in Fully Qualified Database Names are not re-raised

[Django]

#15621: ImportError thrown in Fully Qualified Database Names are not re-raised
-+-
   Reporter: |Owner:  nobody
  keegan_csmith  |Milestone:
 Status:  closed |  Version:  SVN
  Component:  Database   | Keywords:
  layer (models, ORM)|Has patch:  1
 Resolution: |  Needs tests:  0
  worksforme |
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by adrian):

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


Comment:

 I couldn't reproduce the bug. I changed my database engine to
 {{{django.db.backends.oracle}}} (and I don't have cx_Oracle installed on
 this machine), and it raised the correct {{{ImportError}}} --

 {{{
 >>> from django.db import connection
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Library/Python/2.6/site-packages/django/db/__init__.py", line 78,
 in 
 connection = connections[DEFAULT_DB_ALIAS]
   File "django/db/utils.py", line 91, in __getitem__
 backend = load_backend(db['ENGINE'])
   File "django/db/utils.py", line 33, in load_backend
 return import_module('.base', backend_name)
   File "/Library/Python/2.6/site-packages/django/utils/importlib.py", line
 35, in import_module
 __import__(name)
   File "django/db/backends/oracle/base.py", line 46, in 
 raise ImproperlyConfigured("Error loading cx_Oracle module: %s" % e)
 django.core.exceptions.ImproperlyConfigured: Error loading cx_Oracle
 module: No module named cx_Oracle
 }}}

 Please reopen with more information on how to reproduce. Hope I'm not
 missing something obvious!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15618: django.contrib.messages.storage.fallback.CookieStorage does not behave properly with subdomains

[Django]

#15618: django.contrib.messages.storage.fallback.CookieStorage does not behave
properly with subdomains
+--
   Reporter:  lamby |Owner:  nobody
 Status:  closed|Milestone:
  Component:  Contrib apps  |  Version:  1.2
 Resolution:  fixed | Keywords:
   Triage Stage:  Unreviewed|Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by adrian):

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


Comment:

 Note that I opted to use SESSION_COOKIE_DOMAIN here even though this
 technically isn't for django.contrib.sessions. I didn't want to add
 another setting, and I couldn't think of a case where you might want the
 cookie domain to be different for messages vs. sessions. Down the road we
 may want to rename SESSION_COOKIE_DOMAIN to COOKIE_DOMAIN.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15194: Need 'geos_c' as library name for Windows

[Django]

#15194: Need 'geos_c' as library name for Windows
+--
   Reporter:  master|Owner:  jbronn
 Status:  assigned  |Milestone:  1.3
  Component:  GIS   |  Version:  1.2
 Resolution:| Keywords:  geos_c blocker
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by jbronn):

 * keywords:  geos_c => geos_c blocker


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

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

Re: [Django] #12416: Improve KML Serialization

[Django]

#12416: Improve KML Serialization
+
   Reporter:  jbronn|Owner:  jbronn
 Status:  assigned  |Milestone:  1.4
  Component:  GIS   |  Version:  SVN
 Resolution:| Keywords:  gis kml 3d style rhr
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by jbronn):

 * status:  new => assigned
 * milestone:  1.3 => 1.4


Comment:

 Punting again.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #12410: add support for St_Line_Locate_Point to geodjango postgis backend

[Django]

#12410: add support for St_Line_Locate_Point to geodjango postgis backend
-+-
   Reporter:  IanWard|Owner:  jbronn
 Status:  assigned   |Milestone:  1.4
  Component:  GIS|  Version:  SVN
 Resolution: | Keywords:  St_Line_Locate_Point
   Triage Stage:  Design |Has patch:  1
  decision needed|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jbronn):

 * milestone:  1.3 => 1.4


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

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

[Django]

#9806: GeometryField crashes contrib.gis.admin
-+-
   Reporter: |Owner:  jbronn
  ingenieroariel |Milestone:  1.4
 Status:  assigned   |  Version:  1.0
  Component:  GIS| Keywords:  admin, gis,
 Resolution: |  GeometryField
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  1  |
-+-
Changes (by jbronn):

 * milestone:  1.3 => 1.4


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

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

[Django]

#11185: Document how to customize widgets
-+--
   Reporter:  bensmith   |Owner:  fadeev
 Status:  new|Milestone:  1.3
  Component:  Documentation  |  Version:  1.0
 Resolution: | Keywords:  widget
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by fadeev):

 * cc: fadeev (added)
 * owner:  nobody => fadeev


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #14604: Ubuntu documentation for geospatial/Postgres is out of date

[Django]

#14604: Ubuntu documentation for geospatial/Postgres is out of date
+--
   Reporter:  mfitzp|Owner:  nobody
 Status:  closed|Milestone:  1.3
  Component:  GIS   |  Version:  1.2
 Resolution:  fixed | Keywords:  gis
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by jbronn):

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


Comment:

 Fixed in r15536.  Scripts were updated for all Ubuntu/Debian distributions
 and docs were updated to include instructions for latest versions of
 Ubuntu.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15619: Logout link should be a form

[Django]

#15619: Logout link should be a form
+--
   Reporter:  void  |Owner:  nobody
 Status:  closed|Milestone:
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:  wontfix   | Keywords:
   Triage Stage:  Unreviewed|Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by russellm):

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


Comment:

 The [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html HTTP spec] says
 (9.1.1) that GET requests "[http://www.ietf.org/rfc/rfc2119.txt SHOULD
 NOT] have the significance of taking an action other than retrieval", and
 "ought to be considered 'safe'". It also says (9.1.2) that GET has the
 property of idempotence. A logout link is idempotent. Therefore, we are
 HTTP compliant.

 As for CSRF; I fail to see why this is relevant. Given that there is no
 incoming data, and no data processing, I cannot see an CSRF weakness, even
 in-principle.

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

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

[Django]

#15533: OSMGeoAdmin fails on Fedora 14
--+--
   Reporter:  cnorthwood  |Owner:  jbronn
 Status:  assigned|Milestone:  1.3
  Component:  GIS |  Version:  1.2
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  1   |
--+--
Changes (by jbronn):

 * milestone:  1.4 => 1.3


Comment:

 Replying to [comment:3 jbronn]:
 > !OpenLayers will not support 3857 until 2.11, so I'm moving the
 milestone to 1.4.

 After talking with Christopher Schmidt, a one line !JavaScript fix is
 enough until !OpenLayers 2.11 is released.  Initial tests look good,
 should be in trunk and backported soon.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13383: Querysets should only allow the correct model types to be filtered against

[Django]

#13383: Querysets should only allow the correct model types to be filtered 
against
-+-
   Reporter: |Owner:  karahello
  SmileyChris|Milestone:  1.3
 Status:  new|  Version:  SVN
  Component:  Database   | Keywords:
  layer (models, ORM)|Has patch:  0
 Resolution: |  Needs tests:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by karahello):

 * owner:   => karahello


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15611: Readonly fields not hidden during create

[Django]

#15611: Readonly fields not hidden during create
+--
   Reporter:  coderanger|Owner:  jezdez
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by coderanger):

 * owner:  coderanger => jezdez


Comment:

 Also available in git form at
 https://github.com/coderanger/django/commits/ticket-15611

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+---
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:  blocker
   Triage Stage:  Ready for checkin |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  1 |
+---
Changes (by russellm):

 * keywords:   => blocker


Comment:

 Marking as a blocker since it's a regression introduced by a recent change

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution:  needsinfo  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--

Comment (by russellm):

 @jose -- Look very closely at my example. I deliberately mounted 2
 included URLs at the same base -- /foo. Lets say I browse to /foo/bar. It
 doesn't match anything in app1.urls or app2.urls. Do we display the
 app1.handler404 or the app2.handler404? Both app1.urls and app2.urls match
 the /foo prefix -- how do we disambiguate between the two?

 I agree with Adrian -- I'm not convinced that this can be done in a non-
 crufty way. There might be room to do this sort of thing if we rework the
 way URLs are defined, but given the current structure, I'm not sure it can
 be done cleanly and unambiguously.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15621: ImportError thrown in Fully Qualified Database Names are not re-raised

[Django]

#15621: ImportError thrown in Fully Qualified Database Names are not re-raised
--+---
 Reporter:  keegan_csmith | Owner:  nobody
   Status:  new   | Milestone:
Component:  Database layer (models, ORM)  |   Version:  SVN
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  1 |
--+---
 If an !ImportError occurs in a db supplied by django.db.backends it does
 not get re-raised. Instead the error is presented as a user configuration
 error. This only occurs if the backend is specified using a fully
 qualified name.

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

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

[Django] #15620: ClerableFileInput should render initial value in a flexible way

[Django]

#15620: ClerableFileInput should render initial value in a flexible way
---+---
 Reporter:  void   | Owner:  nobody
   Status:  new| Milestone:
Component:  Forms  |   Version:  SVN
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  1  |
---+---
 Currently rendering of ClerableFileInput's initial value is hardcoded a
 bit.
 It would be nice to extract generation of initial value to the method.
 This would allow derived classes to override only this method and not the
 whole render(), as shown in attached patch.

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

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

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+--
   Reporter:  jkocherhans|Owner:  adrian
 Status:  reopened   |Milestone:  1.4
  Component:  Core framework |  Version:  SVN
 Resolution: | Keywords:
   Triage Stage:  Fixed on a branch  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by gsakkis):

 * cc: george.sakkis@… (removed)


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

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

Re: [Django] #13577: New Polish L10N formats file

[Django]

#13577: New Polish L10N formats file
+
   Reporter:  ludwik|Owner:  lrekucki
 Status:  new   |Milestone:  1.3
  Component:  Translations  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+

Comment (by konryd):

 For thinsp / against nbsp:
   *  It honors the standard PN-83 which is polish typesetting standard
 (which I currently don't have access to, and my Google-fu is failing)
 For nbsp / against thinsp:
   * the unbreaking behaviour is desirable
   * thinsp seems esoteric to me (please correct me if I'm wrong)
   * this page says Opera doesn't display thinsp properly:
 http://en.wikipedia.org/wiki/Template:Thinsp
   * CLDR data set confirms this option

 I'd say use nbsp. I'm happy with submitting a patch, but I'm not sure if
 putting unicode there wouldn't break things.

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

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

[Django]

#15603: Don't send HTML emails by default
--+---
   Reporter:  kmtracey|Owner:  adrian
 Status:  new |Milestone:  1.3
  Component:  Core framework  |  Version:  1.3-rc1
 Resolution:  | Keywords:  blocker
   Triage Stage:  Accepted|Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+---

Comment (by jacob):

 I don't think that's quite the right target for a link -- Lumberjack and
 slow-log don't really replace emails the way Sentry does. We probably
 should create an "error email replacements" grid. Better name, though,
 please.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #14045: makemessage miss some gettext in javascript

[Django]

#14045: makemessage miss some gettext in javascript
+
   Reporter:  shaohao   |Owner:  nobody
 Status:  reopened  |Milestone:
  Component:  Internationalization  |  Version:  1.2
 Resolution:| Keywords:  xgettext
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+

Comment (by lrekucki):

 Replying to [comment:7 claudep]:
 > And as jezdez told us on IRC, the middle-term solution would be to use a
 real Javascript parser (not available in xgettext) to extract strings from
 js files (like the one in Babel:
 http://svn.edgewall.org/repos/babel/trunk/babel/messages/jslexer.py).

 +Inf on using a real lexer/parser. See #15495 for another weird bug.

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

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

Re: [Django] #14045: makemessage miss some gettext in javascript

[Django]

#14045: makemessage miss some gettext in javascript
+
   Reporter:  shaohao   |Owner:  nobody
 Status:  reopened  |Milestone:
  Component:  Internationalization  |  Version:  1.2
 Resolution:| Keywords:  xgettext
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+

Comment (by claudep):

 And as jezdez told us on IRC, the middle-term solution would be to use a
 real Javascript parser (not available in xgettext) to extract strings from
 js files (like the one in Babel:
 http://svn.edgewall.org/repos/babel/trunk/babel/messages/jslexer.py).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13584: django.forms FileField does not allow empty files.

[Django]

#13584: django.forms FileField does not allow empty files.
-+-
   Reporter:  jamesh |Owner:  closedbracket
 Status:  new|Milestone:  1.3
  Component:  File   |  Version:  SVN
  uploads/storage| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by closedbracket):

 * owner:  nobody => closedbracket


Comment:

 I updated the patch, test, and docs for 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] #14045: makemessage miss some gettext in javascript

[Django]

#14045: makemessage miss some gettext in javascript
+
   Reporter:  shaohao   |Owner:  nobody
 Status:  reopened  |Milestone:
  Component:  Internationalization  |  Version:  1.2
 Resolution:| Keywords:  xgettext
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+

Comment (by jezdez):

 Yeah, I was able to reproduce this myself, and I first thought it would be
 able to be fixed by changing from using "Perl" to "Python". Guess we need
 to limit the use of gettext to 0.17 for now.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15619: Logout link should be a form

[Django]

#15619: Logout link should be a form
--+---
 Reporter:  void  | Owner:  nobody
   Status:  new   | Milestone:
Component:  django.contrib.admin  |   Version:  SVN
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 There is a logout link in admin app. It is link, not a form. Therefore it
 is not CSRF-protected.
 Probably it is not so important to protect logout from CSRF attack,
 because this fact cannot be used to do anything harmful. So this is just a
 request for purity.
 Another reason is that GET request should never change invernal state of
 the system.

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

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

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+--
   Reporter:  jkocherhans|Owner:  adrian
 Status:  reopened   |Milestone:  1.4
  Component:  Core framework |  Version:  SVN
 Resolution: | Keywords:
   Triage Stage:  Fixed on a branch  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by JMagnusson):

 * cc: JMagnusson (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] #14543: ContentTypes tests fails if auth app is not installed

[Django]

#14543: ContentTypes tests fails if auth app is not installed
+
   Reporter:  sayane|Owner:  dmoisset
 Status:  new   |Milestone:  1.3
  Component:  Contrib apps  |  Version:  SVN
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by crayz_train):

 * needs_better_patch:  1 => 0


Comment:

 This patch implements a bogus User model for the test_shortcut_view to use
 during the test run. Done @ PyCon 2011.

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

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

[Django]

#15533: OSMGeoAdmin fails on Fedora 14
--+--
   Reporter:  cnorthwood  |Owner:  jbronn
 Status:  assigned|Milestone:  1.4
  Component:  GIS |  Version:  1.2
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  1   |
--+--
Changes (by jbronn):

 * milestone:  1.3 => 1.4


Comment:

 !OpenLayers will not support 3857 until 2.11, so I'm moving the milestone
 to 1.4.

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

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

[Django]

#15617: CSRF referer checking too strict
-+-
   Reporter:  adam   |Owner:  lukeplant
 Status:  assigned   |Milestone:
  Component:  Uncategorized  |  Version:  1.3-beta
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * status:  new => assigned
 * owner:  nobody => lukeplant
 * stage:  Unreviewed => Accepted


Comment:

 This is definitely a bug. However, the fix is not so simple, because we
 are using 'startswith' to check the referer, and with the proposed change,
 `https://example.com` could be matched by `https://example.com.evil.com`
 . That is almost certainly why I added that slash.

 The correct way to do with is to compare the (protocol, domain, port)
 triple, as specified here:
 http://www.w3.org/Security/wiki/Same_Origin_Policy

 We could do with a 'same_origin' utility function that is properly tested
 and implements the above check using urlparse, and then is used by the
 middleware.

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

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

Re: [Django] #15525: Custom template tags loading breaks whenever templatetags is a python file

[Django]

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

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


Comment:

 Recreated the traceback in order to add a more specific error:
 {{{
 Environment:

 Request Method: GET
 Request URL: http://127.0.0.1:8000/
 Django Version: 1.2.5
 Python Version: 2.6.6
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.admin',
  'django.contrib.sites',
  'django.contrib.flatpages',
  'dojango',
  'south',
  'reversion',
  'sitetree',
  'tagging',
  'paging',
  'disqus',
  'autoslug',
  'django_generic_flatblocks',
  'cms',
  'blog',
  'testtemplatetagserror']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'dojango.middleware.DojoCollector',
  'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware')


 Traceback:
 File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/base.py"
 in get_response
   100. response = callback(request, *callback_args,
 **callback_kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/django/views/generic/simple.py" in direct_to_template
   17. t = loader.get_template(template)
 File "/usr/local/lib/python2.6/dist-packages/django/template/loader.py" in
 get_template
   157. template, origin = find_template(template_name)
 File "/usr/local/lib/python2.6/dist-packages/django/template/loader.py" in
 find_template
   134. source, display_name = loader(name, dirs)
 File "/usr/local/lib/python2.6/dist-packages/django/template/loader.py" in
 __call__
   42. return self.load_template(template_name, template_dirs)
 File "/usr/local/lib/python2.6/dist-packages/django/template/loader.py" in
 load_template
   48. template = get_template_from_string(source, origin,
 template_name)
 File "/usr/local/lib/python2.6/dist-packages/django/template/loader.py" in
 get_template_from_string
   168. return Template(source, origin, name)
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in __init__
   158. self.nodelist = compile_string(template_string, origin)
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in compile_string
   186. return parser.parse()
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in parse
   282. compiled_result = compile_func(self, token)
 File "/usr/local/lib/python2.6/dist-
 packages/django/template/loader_tags.py" in do_extends
   195. nodelist = parser.parse()
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in parse
   282. compiled_result = compile_func(self, token)
 File "/usr/local/lib/python2.6/dist-
 packages/django/template/loader_tags.py" in do_block
   173. nodelist = parser.parse(('endblock', 'endblock %s' %
 block_name))
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in parse
   282. compiled_result = compile_func(self, token)
 File "/usr/local/lib/python2.6/dist-
 packages/django/template/defaulttags.py" in load
   924. lib = get_library(taglib)
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in get_library
   1040. lib = import_library(taglib_module)
 File "/usr/local/lib/python2.6/dist-packages/django/template/__init__.py"
 in import_library
   992. if not module_has_submodule(app_module, taglib):
 File "/usr/local/lib/python2.6/dist-
 packages/django/utils/module_loading.py" in module_has_submodule
   17. for entry in package.__path__:  # No __path__, then not a
 package.

 Exception Type: AttributeError at /
 Exception Value: 'module' object has no attribute '__path__'

 }}}
 Why does it break on:

 {{{
 nodelist = parser.parse(('endblock', 'endblock %s' % block_name))
 }}}

 And where does the try block begins and ends?

-- 
Ticket URL: 
Django 
The Web framework for 

[Django] #15618: django.contrib.messages.storage.fallback.CookieStorage does not behave properly with subdomains

[Django]

#15618: django.contrib.messages.storage.fallback.CookieStorage does not behave
properly with subdomains
--+---
 Reporter:  lamby | Owner:  nobody
   Status:  new   | Milestone:
Component:  Contrib apps  |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  1 |
--+---
 Imagine you have two domains "www.example.com" and "special.example.com".
 Your `SESSION_COOKIE_DOMAIN` is set to ".example.com" so that users are
 logged-in across these two subdomains.

 The problem arises when a page on "www.example.com" sets a
 `django.contrib.message` and redirects to "special.example.com", the user
 will not see it unless they return to "www.example.com" as the default
 domain of the cookie is the current one. This naturally causes confusion
 as actions users have performed in the past suddenly are being confirmed
 (!).

 This happens with `FallbackStorage` too as it wraps `CookieStorage`.

 Patch attached that sets the domain of the CookieStorage cookie to
 SESSION_COOKIE_DOMAIN. Whilst this works, it might be better to not couple
 `sessions` and `messages` in this way, so we could alternatively introduce
 a new setting under a the `MESSAGE_STORAGE_` namespace.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+--
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Ready for checkin |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  1 |
+--
Changes (by ramiro):

 * stage:  Accepted => Ready for checkin


Comment:

 Replying to [comment:6 mk]:
 > Yes, we do not have any tests. However, we do not have any tests for
 javascript behavior at all currently. Not fixing a JS bug when we do not
 even have **any** automated tests for scripts (not even a blessed testing
 framework...) isn't helpful at all.

 Yes, I discovered that (we don't have tests for JS changes to the DOM)
 when trying to create the regression test, sorry for that, I will move
 this back to RFC although we need to also touch the minified version of
 `inlines.js` before committing.

 FWIW this was introduced in r15422.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+--
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  1 |
+--

Comment (by mk):

 Yes, we do not have any tests. However, we do not have any tests for
 javascript behavior at all currently. Not fixing a JS bug when we do not
 even have **any** automated tests for scripts (not even a blessed testing
 framework...) isn't helpful at all.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+--
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  1 |
+--
Changes (by ramiro):

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


Comment:

 Can't be RFC because has no tests.

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

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

Re: [Django] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+--
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Ready for checkin |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+--
Changes (by mk):

 * stage:  Accepted => Ready for checkin


Comment:

 Right. That is a better patch, as long as the logic isn't fixed
 definitively. Promoting to Ready for checkin because this is a bugfix
 which would be a pity to miss for 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] #15229: URLValidator class to accept ftp links

[Django]

#15229: URLValidator class to accept ftp links
--+--
   Reporter:  codefisher  |Owner:  nobody
 Status:  new |Milestone:
  Component:  Core framework  |  Version:  SVN
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+--
Changes (by crayz_train):

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


Comment:

 PyCon 2011 sprint.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15569: wrong index assigned when creating a new inline

[Django]

#15569: wrong index assigned when creating a new inline
+--
   Reporter:  sbaechler |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+--

Comment (by Arthur de Jong ):

 I was also bitten by this (found in 1.3-rc-1, not in 1.2.1). We came up
 with a slightly different patch that does not change what is called
 exactly but just ensures that the values are set consistently.

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

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

[Django]

#15614: Documentation typo
-+--
   Reporter:  anonymous  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Uncategorized  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by adrian):

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


Comment:

 Good catch. Looks like we have the same problem with {{{redirect_to}}} in
 that same document. I'm working on a fix...

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

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

Re: [Django] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution:  needsinfo  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--

Comment (by adrian):

 So basically jose is saying you should be able to override the global
 handler404 and handler500 within a "child" urls.py. I think this wouldn't
 be worth adding, because it would be adding cruft to an already-crufty
 API. (I'd like to make a cleaner way of doing handler404/handler500 down
 the road -- it seems crufty as-is.)

 jose: You can accomplish what you want by returning a custom HttpResponse
 class from your view with {{{status_code}}} 404, like this:

 {{{
 response = render_to_response('custom_404_template.html', context)
 response.status_code = 404
 return response
 }}}

 If you don't want to do this from every view, you can write a middleware
 that catches 404s and does different things depending on context/URL.

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

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

[Django]

#15533: OSMGeoAdmin fails on Fedora 14
--+--
   Reporter:  cnorthwood  |Owner:  jbronn
 Status:  assigned|Milestone:  1.3
  Component:  GIS |  Version:  1.2
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  1   |
--+--
Changes (by jbronn):

 * owner:  nobody => jbronn
 * status:  new => assigned
 * needs_better_patch:  0 => 1
 * milestone:   => 1.3


Comment:

 Apparently the Fedora packagers didn't like the licensing of the
 `cubewerx_extra.wkt` file where 900913 lives.  3857 was added in GDAL 1.7,
 thus we need to try and support previous versions.

 I agree this is a bug, but I'm -1 on the patch implementation.  The right
 thing to do would be to introspect on the GDAL version, and use 3857 when
 1.7+ is used, and 900913 otherwise.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #14765: Unnecessary usage of NodeList in ForNode (template rendering)

[Django]

#14765: Unnecessary usage of NodeList in ForNode (template rendering)
---+--
   Reporter:  anonymous|Owner:  nobody
 Status:  new  |Milestone:
  Component:  Template system  |  Version:  SVN
 Resolution:   | Keywords:  ForNode render
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--

Comment (by adrian):

 Just took a look at this patch. I don't see a reason for
 {{{mark_safe_unicode}}} to be a classmethod (not being a big fan of
 classmethods). Can you change it to be a module-level 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] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |Milestone:
 Status:  assigned   |  Version:  SVN
  Component: | Keywords:  nfa-someday
  django.contrib.admin   |  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by ramiro):

 #15615 (closed as duplicate) asks for the same feature.

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

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

Re: [Django] #15615: filterspec feature

[Django]

#15615: filterspec feature
+--
   Reporter:  duzy84@…  |Owner:  nobody
 Status:  closed|Milestone:  1.4
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:  duplicate | Keywords:  filter
   Triage Stage:  Unreviewed|Has patch:  0
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+--
Changes (by ramiro):

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


Comment:

 Duplicate of #5833.

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

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

[Django]

#15617: CSRF referer checking too strict
-+
   Reporter:  adam   |Owner:  nobody
 Status:  new|Milestone:
  Component:  Uncategorized  |  Version:  1.3-beta
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by anonymous):

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


Comment:

 The above urls should all be the same except for the trailing slash. I've
 obfuscated the url because the site is not yet public.

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

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

[Django]

#15617: CSRF referer checking too strict
---+---
 Reporter:  adam   | Owner:  nobody
   Status:  new| Milestone:
Component:  Uncategorized  |   Version:  1.3-beta
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 I get this error:

 Forbidden (403)
 CSRF verification failed. Request aborted.

 Reason given for failure:

 Referer checking failed - https://sub.domain.com does not match
 https://sum.domain.com/.

 Using IE6 on my site. In the apache log the request looks like:

 86.24.194.171 - - [15/Mar/2011:15:07:06 +] "POST / HTTP/1.1" 403 1030
 "https://sub.domain.com; "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;
 .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

 So it looks like the referer should not be required to start with a url
 including a trailing slash. That is a change to make:

 good_referer = 'https://%s' % request.get_host()

 Happy to provide a patch if people agree with my conclusions.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #6870: pre_delete should be sent before collecting ForeignKey relationships

[Django]

#6870: pre_delete should be sent before collecting ForeignKey relationships
-+-
   Reporter: |Owner:  nobody
  wkornewald |Milestone:
 Status:  new|  Version:  SVN
  Component:  Database   | Keywords:  pre_delete signals
  layer (models, ORM)|  related
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by koto):

 * cc: code@… (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] #15616: django.core.exceptions.ValidationError is poorly implemented and documented

[Django]

#15616: django.core.exceptions.ValidationError is poorly implemented and 
documented
+---
 Reporter:  tomevans223 | Owner:  nobody
   Status:  new | Milestone:
Component:  Core framework  |   Version:  SVN
 Keywords:  validation validationerror  |  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 django.core.exceptions.ValidationError has a horrific interface. It's
 publicly accessible attributes differ depending upon how the object is
 created, as do the pre/post conditions for it's publicly accessible
 methods.

 If constructed with a dictionary of error messages, then it gets an
 attribute 'message_dict'.
 If constructed with a string, or a list of strings, then it gets an
 attribute 'messages'.
 The documentation on Model.clean() talks about ValidationError, but does
 not mention this at all, and instructs the user to look at messages_dict.
 [1]

 If constructed with a dictionary of error messages, then the method
 update_error_dict(self, error_dict) will happily accept error_dict=None -
 it checks for and handles this condition. If constructed with a string or
 list, then not supplying error_dict is an error.

 This sort of inconsistent behaviour is hard to explain. At the least, this
 behaviour should be documented clearly, but ideally the interface should
 be consistent, regardless of how it is constructed.

 [1]
 
http://docs.djangoproject.com/en/dev/ref/models/instances/#django.db.models.Model.clean

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

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

[Django]

#15615: filterspec feature
+--
   Reporter:  duzy84@…  |Owner:  nobody
 Status:  new   |Milestone:  1.4
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:  filter
   Triage Stage:  Unreviewed|Has patch:  0
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+--
Changes (by farciarz ):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 1
 * milestone:  1.3 => 1.4


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

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

[Django]

#15615: filterspec feature
--+---
 Reporter:  duzy84@…  | Owner:  nobody
   Status:  new   | Milestone:  1.3
Component:  django.contrib.admin  |   Version:  1.2
 Keywords:  filter|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 == Filter customization ==

 The lack of filter customization in django admin documentation gives me
 the reason to write some sample. The filters are made on
 '''DateTimeFiled''' and distinguish objects by '''month''' and '''year'''.
 However each filter applied on one field works - applying them both is not
 familiar to me and I have no clue how to do this. One workaround is to
 make a fake field which is the copy of reference filed and apply the next
 filter on the fake, but for sure there is more elegant solution e.g
 changing GET request. The code suffers from lack of unit testing.

 {{{#!python
 #app/filters.py

 from django.db import models
 from django.contrib.admin.filterspecs import FilterSpec,
 DateFieldFilterSpec
 from django.utils.translation import ugettext as _
 import datetime

 class MonthFilterSpec(DateFieldFilterSpec):

   def __init__(self, f, request, params, model, model_admin):
 super(MonthFilterSpec, self).__init__(f, request, params, model,
 model_admin)
 self.field_generic = '%s__' % self.field.name

 self.parsed_params = dict([(k, v) for k, v in params.items() if
 k.startswith(self.field_generic)])
 self.values = [int(v) for k, v in self.parsed_params.iteritems()]

 self.links = (
   (_('Any month'), {}),
   (_('January'), {'%s__month' % self.field.name: 1, }),
   (_('February'), {'%s__month' % self.field.name: 2, }),
   (_('March'), {'%s__month' % self.field.name: 3, }),
   (_('April'), {'%s__month' % self.field.name: 4, }),
   (_('May'), {'%s__month' % self.field.name: 5, }),
   (_('June'), {'%s__month' % self.field.name: 6, }),
   (_('July'), {'%s__month' % self.field.name: 7, }),
   (_('August'), {'%s__month' % self.field.name: 8, }),
   (_('September'), {'%s__month' % self.field.name: 9, }),
   (_('October'), {'%s__month' % self.field.name: 10, }),
   (_('November'), {'%s__month' % self.field.name: 11, }),
   (_('December'), {'%s__month' % self.field.name: 12, }),
 )

   def title(self):
 return _("Month")

   def choices(self, cl):
 for title, param_dict in self.links:
   yield {'selected':  param_dict.get('%s__month'%self.field.name, '')
 in self.values or param_dict==self.parsed_params,
  'query_string': cl.get_query_string(param_dict,
 [self.field.name]),
  'display': title}


 class YearFilterSpec(DateFieldFilterSpec):

   def __init__(self, f, request, params, model, model_admin):
 super(YearFilterSpec, self).__init__(f, request, params, model,
 model_admin)
 year = int(datetime.date.today().year)

 self.field_generic = '%s__' % self.field.name
 self.parsed_params = dict([(k, v) for k, v in params.items() if
 k.startswith(self.field_generic)])
 self.values = [str(v) for k, v in self.parsed_params.items()]

 self.links = (
   (_('Any year'), {}),
   (_('%s'%str(year-1)), {'%s__year' % self.field.name: year-1, }),
   (_('%s'%str(year)), {'%s__year' % self.field.name: year, }),
   (_('%s'%str(year+1)), {'%s__year' % self.field.name: year+1, }),
 )


   def title(self):
 return _("Year")

   def choices(self, cl):
 for title, param_dict in self.links:
   yield {'selected':  title in self.values or
 param_dict==self.parsed_params,
  'query_string': cl.get_query_string(param_dict,
 [self.field.name]),
  'display': title}


 FilterSpec.filter_specs.insert(0, (lambda f: getattr(f, 'year_filter',
 False), YearFilterSpec))
 FilterSpec.filter_specs.insert(0, (lambda f: getattr(f, 'month_filter',
 False), MonthFilterSpec))

 #app/models.py
 start = models.DateField(_('start'), unique_for_date=True)
 start.month_filter = True
 start.year_filter = True

 #app/admin.py
 from app.filters import MonthFilterSpec, YearFilterSpec
 list_filter = ('start', )

 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution:  needsinfo  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--

Comment (by jose):

 Okay, your example case is the best way to explain my situation, because
 is just that I did in the Django project which I am working :)

 So, we have two Django apps in the same project, app1 and app2, each of
 them with its own 'urls.py' file where the URL routing is specified. My
 case is that I want to specify a different 'handler404 = ...' and a
 'handler500 = ' in each 'urls.py' file. Then when you type, for
 example, 'http:/mysite.com/app1/BAD_URL' you get the 404.html template
 specified in the app1 views, and if you type
 'http://mysite.com/app2/BAD_URL' you get the 404.html template specified
 in the app2 views. And the same for the 500 errors.

 Now, this is not possible because you only can do this in the project
 'urls.py' and the handler404 and handler500 must be the same for all the
 applications involved in the project.

 This is what I am referring when I asked for a custom error handler for an
 app.

 Cheers.
 Jose

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

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

[Django]

#15614: Documentation typo
---+---
 Reporter:  anonymous  | Owner:  nobody
   Status:  new| Milestone:
Component:  Uncategorized  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 On this page: http://docs.djangoproject.com/en/1.2/ref/generic-views/

 When I try the example for the direct_to_template:

 {{{
 (r'^foo/$', 'direct_to_template', {'template':
 'foo_index.html'}),
 }}}

 I got a ''str object is not callable'' error.

 If I remove the quotes around ''direct_to_template'' it does work.

 {{{
 (r'^foo/$', direct_to_template, {'template':
 'foo_index.html'}),
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution:  needsinfo  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  reopened   |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15613: django.views.static.serve gives incorrect Content-Length with non-regular files

[Django]

#15613: django.views.static.serve gives incorrect Content-Length with 
non-regular
files
---+---
 Reporter:  jaylett| Owner:  nobody
   Status:  new| Milestone:  1.3
Component:  Uncategorized  |   Version:  1.3-beta
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  1  |
---+---
 Because of changes introduced related to #15281, Content-Length is
 currently calculated using `statobj.st_size`. This fails if serving from
 eg a named pipe, since st_size will be 0; user agents may then close the
 connection while Django is still sending the actual response data, causing
 a broken pipe in runserver and of course no useful data being provided to
 the user agent.

 (Named pipes are useful during development if you're using anything that
 automatically preprocesses CSS or Javascript, for instance.)

 The following tiny patch fixes things:

 {{{

 --- Django-1.3-rc-1/django/views/static.py  2011-03-02
 10:40:48.0 +
 +++ ENV/lib/python2.6/site-packages/django/views/static.py  2011-03-14
 14:27:25.0 +
 @@ -5,6 +5,7 @@

  import mimetypes
  import os
 +import stat
  import posixpath
  import re
  import urllib
 @@ -58,7 +59,8 @@
  return HttpResponseNotModified(mimetype=mimetype)
  response = HttpResponse(open(fullpath, 'rb').read(),
 mimetype=mimetype)
  response["Last-Modified"] = http_date(statobj.st_mtime)
 -response["Content-Length"] = statobj.st_size
 +if stat.S_ISREG(statobj.st_mode):
 +response["Content-Length"] = statobj.st_size
  if encoding:
  response["Content-Encoding"] = encoding
  return response
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3496: WSGI handler dies on a form containing only empty checkboxes

[Django]

#3496: WSGI handler dies on a form containing only empty checkboxes
-+-
   Reporter:  mikko@…|Owner:  nobody
 Status:  closed |Milestone:
  Component:  Core   |  Version:  SVN
  framework  | Keywords:  wsgi checkbox post
 Resolution:  fixed  |  request zero
   Triage Stage: |Has patch:  1
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

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


Comment:

 After 3 years this is surely a somewhat different problem than the
 original so it deserves its own ticket. Also FWIW I cannot recreate any
 problem with the wsgi handler and a content length of 0 (using
 Apache/mod_wsgi, so the issue may be related to uwsgi specifically). Using
 this view:

 {{{
 #!python
 from django import forms
 from django.shortcuts import render
 from django.views.decorators.csrf import csrf_exempt

 class YNForm(forms.Form):
 yes_or_no = forms.BooleanField(required=False)

 @csrf_exempt
 def testme(request):
 if request.method == 'POST':
 ynform = YNForm(request.POST)
 msg = 'Posted successfully, content length is %s, request.POST is
 %r' % \
 (request.META['CONTENT_LENGTH'], request.POST)
 else:
 ynform = YNForm()
 msg = 'Blank form retrieved via %s' % request.method
 return render(request, 'ynform.html', {'msg': msg, 'form': ynform})
 }}}

 and this template:

 {{{
 http://www.w3.org/1999/xhtml; lang="en-us" xml:lang="en-us" >
 
 Yes or No?
 
 
 {{ msg }}
 
 {{ form.as_p }}
 Submit
 
 
 
 }}}

 I when I click the link to post the form without having the checkbox
 checked the message I get back is:

 {{{
 Posted successfully, content length is 0, request.POST is 
 }}}

 To investigate whatever issue you are seeing, please open a new ticket
 with more specifics (as above) of what exactly your view/submitting HTML
 looks like.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15579: Please add support to delete specialization , while preserving base class instance (multi-table inheritance)

[Django]

#15579: Please add support to delete specialization , while preserving base 
class
instance (multi-table inheritance)
-+-
   Reporter:  zimnyx |Owner:  nobody
 Status:  reopened   |Milestone:
  Component:  Database   |  Version:  SVN
  layer (models, ORM)| Keywords:
 Resolution: |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by zimnyx):

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


Comment:

 It doesn't seem to work.

 Please take a look on this sample code:
 {{{
 class List(models.Model):
 name = models.CharField(max_length=10)

 class SpecificList(List):
 specific_name = models.CharField(max_length=10)
 }}}

 Let's create specialization instance
 {{{
 >>> s = SpecificList(name='bear', specific_name='sasquatch')
 >>> s.save()
 110315 11:48:3521 Query INSERT INTO `list_list` (`name`) VALUES
 ('bear')
21 Query commit
21 Query SELECT ** FROM `list_specificlist` WHERE
 `list_specificlist`.`list_ptr_id` = 3  LIMIT 1
21 Query INSERT INTO `list_specificlist`
 (`list_ptr_id`, `specific_name`) VALUES (3, 'sasquatch')
21 Query commit
 }}}

 And now delete (upcast) it as you suggested:

 {{{
 >>> s.list_ptr = None
 Traceback (most recent call last):
   File "", line 1, in 
   File "/srv/django-bugi/nowa/mypro/django/db/models/fields/related.py",
 line 327, in __set__
 (instance._meta.object_name, self.field.name))
 ValueError: Cannot assign None: "SpecificList.list_ptr" does not allow
 null values.
 }}}

 I also tried setting *_ptr_id to None and then delete:

 {{{
 >>> s.list_ptr_id = None
 >>> s.delete()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/srv/django-bugi/nowa/mypro/django/db/models/base.py", line 577,
 in delete
 assert self._get_pk_val() is not None, "%s object can't be deleted
 because its %s attribute is set to None." % (self._meta.object_name,
 self._meta.pk.attname)
 AssertionError: SpecificList object can't be deleted because its
 list_ptr_id attribute is set to None.
 }}}

 This does not work either.


 Do I misunderstood you or this feature just doesn't work?

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

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

Re: [Django] #15612: inspectdb guesses wrong field length

[Django]

#15612: inspectdb guesses wrong field length
-+-
   Reporter:  Michael|Owner:  nobody
  Roeller |Milestone:
 Status:  closed |  Version:  1.2
  Component:  django-| Keywords:
  admin.py inspectdb |Has patch:  0
 Resolution:  duplicate  |  Needs tests:  0
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

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


Comment:

 This is #5725.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3496: WSGI handler dies on a form containing only empty checkboxes

[Django]

#3496: WSGI handler dies on a form containing only empty checkboxes
-+-
   Reporter:  mikko@…|Owner:  nobody
 Status:  reopened   |Milestone:
  Component:  Core   |  Version:  SVN
  framework  | Keywords:  wsgi checkbox post
 Resolution: |  request zero
   Triage Stage: |Has patch:  1
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jvdongen):

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


Comment:

 I'm currently running into this issue again, using Django trunk, revision
 15821. Replication is simple: submit an empty form (all checkboxes
 unchecked) and try to access request.POST in view. The wsgi handler dies
 as soon as you try to access request.POST. Putting a single hidden form
 input on the form solves the issue.

 The source code of the wsgi handler seems to be significantly modified
 since this patch was created and applied - so far I've been unable to pin
 down the exact location where the bug originates, as Django does not emit
 any debugging information in this case (I've tried adding extra debug
 logging at various places early in the request processing chain - but they
 don't output anything).

 My wsgi container (uwsgi) does output the following it its logging (with
 harakiri mode disabled - otherwise the django process is simply killed
 after 10 seconds), but I suspect that this is just the end game of a
 situation where Django's trying to read something that isn't there:

 SIGPIPE: writing to a closed pipe/socket/fd (probably the client
 disconnected) on request // !!!
 writev(): Broken pipe [wsgi_headers.c line 168]
 SIGPIPE: writing to a closed pipe/socket/fd (probably the client
 disconnected) on request // !!!
 write(): Broken pipe [pyutils.c line 101]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15568: IntegrityError rises from test test_generic_key_deletion when it runs with the test test_generic_key_cross_database_protection for the INNODB

[Django]

#15568: IntegrityError rises from test test_generic_key_deletion when it runs 
with
the test test_generic_key_cross_database_protection for the INNODB
-+-
   Reporter: |Owner:  nobody
  rahul.priyadarshi@…|Milestone:
 Status:  reopened   |  Version:  1.3-rc1
  Component:  Database   | Keywords:
  layer (models, ORM)|Has patch:  0
 Resolution: |  Needs tests:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by rahul.priyadarshi@…):

 Yes. In my case since i was updating the DB2 django adpater for Django
 1.3, i was using 2 DB2 databases. FWIW first time we had added value to
 Django even before a release has been made. Hey am I am getting better at
 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] #15231: Admin DateTimeShortcuts + Inlines performance

[Django]

#15231: Admin DateTimeShortcuts + Inlines performance
+--
   Reporter:  fabianbuechler|Owner:  nobody
 Status:  new   |Milestone:
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by fabianbuechler):

 * needs_better_patch:  1 => 0


Comment:

 Update patch to add some minor improvements to calendar/clock closing
 behaviour (duplicate patch due to me forgetting to check "replace
 attachment, sorry).
 Unset "Patch needs improvement" flag because airstrike's problems are
 based upon his overwritten base.html template.

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

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

[Django]

#15606: Django admin filter and Bool choices
+--
   Reporter:  django@…  |Owner:  nobody
 Status:  new   |Milestone:
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by russellm):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Uncategorized => django.contrib.admin
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The problem here is the fact that you've used choices on a BooleanField;
 as a result of this, the "choices" filterspec is used, rather than the
 "boolean" filterspec.

 This can be corrected by registering the Boolean filterspec first -- that
 way, the Boolean field will always get the 0/1 filter required by a
 boolean field.

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

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

[Django]

#15612: inspectdb guesses wrong field length
-+-
 Reporter:  Michael Roeller   | Owner:  nobody
   Status:  new  | Milestone:
Component:  django-admin.py inspectdb|   Version:  1.2
 Keywords:   |  Triage Stage:
Has patch:  0|  Unreviewed
-+-
 When I run inspectdb against the following table
 {{{
 CREATE TABLE IF NOT EXISTS `REPORT_NAGIOS_SUBSERVICE` (
   `NAGIOS_SUB_SLA_ID` varchar(100) NOT NULL,
   `NAGIOS_SLA_ID` varchar(100) NOT NULL,
   `SAP_NUMMER` varchar(20) NOT NULL,
   `SERVICE_LEVEL_ID` varchar(50) NOT NULL,
   `SUBSERVICE_ID` varchar(50) NOT NULL,
   `ANZAHL_MESSPKT_GESAMT` int(3) DEFAULT NULL,
   `ANZAHL_MESSPKT_GEWICHTET` int(3) DEFAULT NULL,
   `ANZAHL_MESSPKT_LIMIT` int(3) DEFAULT NULL,
   `KOMMENTAR` varchar(1000) DEFAULT NULL,
   `TS_CREATE` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
 CURRENT_TIMESTAMP,
   `TS_UPDATE` timestamp NOT NULL DEFAULT '-00-00 00:00:00',
   PRIMARY KEY (`NAGIOS_SUB_SLA_ID`),
   UNIQUE KEY `SAP_NUMMER` (`SAP_NUMMER`,`SUBSERVICE_ID`),
   UNIQUE KEY `NAGIOS_SLA_ID` (`NAGIOS_SLA_ID`,`SUBSERVICE_ID`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 }}}

 It produces the following output:
 {{{
 class ReportNagiosSubservice(models.Model):
 nagios_sub_sla_id = models.CharField(max_length=300, primary_key=True,
 db_column='NAGIOS_SUB_SLA_ID') # Field name made lowercase.
 nagios_sla_id = models.CharField(unique=True, max_length=300,
 db_column='NAGIOS_SLA_ID') # Field name made lowercase.
 sap_nummer = models.CharField(unique=True, max_length=60,
 db_column='SAP_NUMMER') # Field name made lowercase.
 service_level_id = models.CharField(max_length=150,
 db_column='SERVICE_LEVEL_ID') # Field name made lowercase.
 subservice_id = models.CharField(unique=True, max_length=150,
 db_column='SUBSERVICE_ID') # Field name made lowercase.
 anzahl_messpkt_gesamt = models.IntegerField(null=True,
 db_column='ANZAHL_MESSPKT_GESAMT', blank=True) # Field name made
 lowercase.
 anzahl_messpkt_gewichtet = models.IntegerField(null=True,
 db_column='ANZAHL_MESSPKT_GEWICHTET', blank=True) # Field name made
 lowercase.
 anzahl_messpkt_limit = models.IntegerField(null=True,
 db_column='ANZAHL_MESSPKT_LIMIT', blank=True) # Field name made lowercase.
 kommentar = models.CharField(max_length=3000, db_column='KOMMENTAR',
 blank=True) # Field name made lowercase.
 ts_create = models.DateTimeField(db_column='TS_CREATE') # Field name
 made lowercase.
 ts_update = models.DateTimeField(db_column='TS_UPDATE') # Field name
 made lowercase.
 class Meta:
 db_table = u'REPORT_NAGIOS_SUBSERVICE'
 }}}

 As you can see the model field-length is three times the original field-
 length.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15607: Custom error templates in a single Django application

[Django]

#15607: Custom error templates in a single Django application
-+--
   Reporter:  jose   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  HTTP handling  |  Version:  1.2
 Resolution:  needsinfo  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by russellm):

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


Comment:

 It's not entirely clear to me what is being proposed here. At a high
 level, having multiple handlers for 404 and 500 errors sounds like a
 reasonable idea, but I'm not sure how this would be interpreted in
 practice.

 In particular -- what delineates the "app" boundary that decides which
 error page is used? An "App" isn't something that has a clear boundary --
 it's just a collection of views. Consider the following pathological, but
 entirely legal case:

 {{{
 urlpatterns = patterns('',
 (r'^foo/', include('app1.urls')),
 (r'^foo/', include('app2.urls')),
 )
 }}}

 How do you define a custom 404/500 handler for 'app1', and under what
 circumstances is it invoked?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15611: Readonly fields not hidden during create

[Django]

#15611: Readonly fields not hidden during create
+--
   Reporter:  coderanger|Owner:  coderanger
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--

Comment (by coderanger):

 The flag was set on the request of Jannis ;-) The fix is done, going to
 make some tests tomorrow when I get down to the sprints.

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

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

[Django]

#15608: Adding es_NI locale
+---
   Reporter:  fitoria   |Owner:  fitoria
 Status:  reopened  |Milestone:
  Component:  Internationalization  |  Version:  SVN
 Resolution:| Keywords:  locale
   Triage Stage:  Ready for checkin |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by russellm):

 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
--+--
   Reporter:  legutierr   |Owner:  nobody
 Status:  new |Milestone:
  Component:  Contrib apps|  Version:  SVN
 Resolution:  | Keywords:
   Triage Stage:  Design decision needed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+--
Changes (by russellm):

 * needs_docs:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 This isn't a minor problem to fix, but it's definitely a problem.

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

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

Re: [Django] #15611: Readonly fields not hidden during create

[Django]

#15611: Readonly fields not hidden during create
+--
   Reporter:  coderanger|Owner:  coderanger
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by russellm):

 * keywords:  blocker =>
 * stage:  Unreviewed => Accepted


Comment:

 FYI: blocker doesn't mean "this is annoying and I want someone to fix it".
 It means "this is a problem so serious that we need to hold back the
 release".

 This *certainly* isn't a blocker. It doesn't cause data loss. It doesn't
 cause crashes. It isn't a regression in behavior since the last release,
 and it isn't a bug in a new feature. It is, at best, an mild annoyance.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15611: Readonly fields not hidden during create

[Django]

#15611: Readonly fields not hidden during create
+--
   Reporter:  coderanger|Owner:  coderanger
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:| Keywords:  blocker
   Triage Stage:  Unreviewed|Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by coderanger):

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


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

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

Re: [Django] #15525: Custom template tags loading breaks whenever templatetags is a python file

[Django]

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

 * needs_tests:  0 => 1


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

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

Re: [Django] #15525: Custom template tags loading breaks whenever templatetags is a python file

[Django]

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

 * needs_better_patch:  0 => 1


Comment:

 Please improve the error to something along the lines of: "Unable to load
 template tags. templatetags must be a module but templatetags.py was
 probably found in %app_name%"

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

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

[Django] #15611: Readonly fields not hidden during create

[Django]

#15611: Readonly fields not hidden during create
--+---
 Reporter:  coderanger| Owner:  coderanger
   Status:  new   | Milestone:  1.3
Component:  django.contrib.admin  |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 A field marked as readonly should be hidden when creating a new object
 from the admin.

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

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