Re: [Django] #19845: AUTH_USER_MODEL not accept sub application.

[Django]

#19845: AUTH_USER_MODEL not accept sub application.
---+--
 Reporter:  eltonplima@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by matt@…):

 I was receiving the following validation error when running `django-
 admin.py validate`:
 ImproperlyConfigured: AUTH_USER_MODEL refers to model
 'account.CustomUser' that has not been installed

 The culprit was an `ImportError` in my `account.models` file.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19886: documentation: FormWizard.as_view() does not have the attribute get_form()

[Django]

#19886: documentation: FormWizard.as_view() does not have the attribute 
get_form()
---+--
 Reporter:  gandalf013@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timo):

 You can't initialize `ContactWizard` directly with a list of forms and the
 initial dict. The `as_view` call is correct, but then you need to pass
 `request` to the function that's returned. Maybe `RequestFactory` could be
 used for the example, but a session is also needed on the request so it
 seems a bit complicated to have this example use the shell.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19888: MultiValueDictKeyError when saving Inlines without an AutoField

[Django]

#19888: MultiValueDictKeyError when saving Inlines without an AutoField
-+-
 Reporter:  nickname123  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 It's not clear at this point if this should be categorized as an ORM bug
 or an admin bug; it seems like it might have its roots in the ORM, but so
 far the only failing example is in 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19887: ModelAdmin.fields and ModelAdmin.fieldset not very detailed documented

[Django]

#19887: ModelAdmin.fields and ModelAdmin.fieldset not very detailed documented
-+-
 Reporter:  Patrick Strasser |Owner:  nobody
  |   Status:  new
 Type:  New feature  |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => New feature
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I've noticed this omission before; I think it would be reasonable for the
 `fields`/`fieldsets` documentation to make some note of what non-fields
 are allowed and under what circumstances.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19888: MultiValueDictKeyError when saving Inlines without an AutoField

[Django]

#19888: MultiValueDictKeyError when saving Inlines without an AutoField
--+
 Reporter:  nickname123   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Saving an Inline that makes use of an autogenerated primary key that is
 not an AutoField causes a MultiValueDictKeyError.

 Here is a gist with an admin.py and model.py to reproduce the issue:
 https://gist.github.com/jacobian/5017514

 Steps:
 create Author
 save
 add a Book to Author
 save
 add another Book to Author
 save --> MultiValueDictKeyError


 Here is an IRC chat log about the issue:

 {{{
 [18:22]  I posted a message to the django-dev group earlier about
 #12235.  I need to use a uuid primary key.  I've added the solution to my
 field, but django is trying to populate it with an integer because the
 suggested solution in the ticket is to imitate an autofield.  Is that the
 right way to fix the issue?
 [18:22]  https://code.djangoproject.com/ticket/12235
 [18:23]  I get a ValueError when I try to add the instance because of
 this
 [18:23]  gp: sorry for stupid question, but why do you need to
 mark the field as autofield?
 [18:24]  and what DB are you using?
 [18:26]  if mysql I can see the reason, Django will helpfully
 issue a select last_insert_id() and populate the field using that value...
 [18:26]  akaariai_: sqlite3 and mysql
 [18:26]  yeah, likely similar problem on sqlite3 too
 [18:27]  so, what happens if the field isn't an autofield?
 [18:27]  akaariai_: MultiValueDict error
 [18:27]  it has to do with inlines
 [18:28]  The summary of the ticket was that everyone's UUIDField
 implementation is wrong.  The suggested fix was to mark the field as an
 AutoField in the contribute_to_class method
 [18:30]  I have to say I still think it's an implementation
 problem. I have plenty of models with non-integer primary keys (slug
 fields, often) and those seem to work fine.
 [18:30]  Unless there's some reason why a uuid, specifically,
 causes Django to fail when it doesn't have an autofield primary key I
 can't really see that this is a bug in Django.
 [18:31]  jacobkm: are those fields automatically filled in?
 [18:31]  gp: I'd have to check specifically where, but yeah they
 kinda have to be.
 [18:32]  jacobkm: are any of them open?  I would like to plug on into
 my model and see if it works.  Would help me narrow the issue down
 [18:32]  gp: can you reproduce the problem with a field built
 into Django? i.e. char field or seomthing?
 [18:33]  gp: if so, then it's certainly a bug in Django. If not,
 it still might be a bug in Django, but it also implies there's more going
 on.
 [18:34]  jacobkm: I will copy over the relavent code to a charfield
 subclass.  The field is basically a charfield on everything but postgres
 [18:34]  will report back
 [18:35]  jacobkm: are you setting the field as autofield?
 [18:35]  akaariai_: I doubt it, that seems wrong to me.
 [18:36]  agreed
 [18:36]  jacobkm: the suggested fix to that issue was to use
 cls._meta.has_auto_field = True and cls._meta.auto_field = self in the
 fields contribute_to_class method
 [18:36]  gp: yeah i don't think that should be needed.
 [18:36]  jacobkm: okay good.
 [18:53]  here is the field: http://dpaste.com/971742/
 [18:53]  I still get the MultiValueDictKeyError
 [18:55]  Have a model and an inline model.  Create an instance of the
 model.  Save it.  Add one child... save it.  Add another child... save =
 MultiValueDictKeyError
 [18:56]  gp: beat me to it :)
 [18:56]  It doesn't actually require a custom field:
 https://gist.github.com/5017514
 [18:56]  So yeah, bug.
 [19:00]  hmmh, so the problem is that the has_auto_field has
 dual meaning - first, it is used to determine if the field is
 autogenerated, but also if it is autogenerated in the DB
 [19:01]  think it is a difficult fix?
 [19:05]  I would be happy to put it together if someone gave me some
 guidance on how it should be done
 [19:06]  akaariai_: I think that is the issue
 [19:06]  gp: A possible idea is to add field.autogenerated,
 meaning is that the field's value will be automatically generated on first
 save, and isn't user editable.
 [19:07]  then the meta.has_auto_field would point to true
 AutoFields only. Go through all instances where has_auto_field is used and
 determine if has_auto_field or field.autogenerated should be used.
 [19:07]  might work, but I wouldn't be surprised if it doesn't.
 [19:07]  all instances -> all places in django code...
 [19:08]  akaariai_: that makes sense
 [19:10]  Is this something that could get into the 1.5 or will it have
 to wait?
 [19:10]  g

[Django] #19887: ModelAdmin.fields and ModelAdmin.fieldset not very detailed documented

[Django]

#19887: ModelAdmin.fields and ModelAdmin.fieldset not very detailed documented
--+
 Reporter:  Patrick Strasser   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 ModelAdmin.fields and ModelAdmin.fieldset are not very detailed documented
 compared to ModelAdmin.display_list. It is not clear if only fields or
 callables too can be used, and how to do so. In fact, callables need to be
 in readonly_fields, which is quite logical after you found out, but no
 hint is given in the documentation.

 This could be presented in comparison to the "list" display properties,
 where you have to state so if you want to make fields editable.

 Maybe noteworth is some hint about callables that you want to make
 writable. I guess in that case a custom Field would be the Right Thing
 (?).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] dcf651: Fixed Oracle specific failures in commands_sql tes...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: dcf651c27edff13236fda0a480059b57dbe6e074
  
https://github.com/django/django/commit/dcf651c27edff13236fda0a480059b57dbe6e074
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M tests/regressiontests/commands_sql/tests.py

  Log Message:
  ---
  Fixed Oracle specific failures in commands_sql tests



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19846: Simplify BlockContext code with defaultdict

[Django]

#19846: Simplify BlockContext code with defaultdict
--+
 Reporter:  FunkyBob  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Template system   |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"e5a8df06be8ce82f5ba10dca5087339704ffd0fa"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e5a8df06be8ce82f5ba10dca5087339704ffd0fa"
 Fixed #19846 -- Optimized a dict of lists in BlockContext class

 Thanks Curtis Maloney for the report and the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e5a8df: Fixed #19846 -- Optimized a dict of lists in Block...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e5a8df06be8ce82f5ba10dca5087339704ffd0fa
  
https://github.com/django/django/commit/e5a8df06be8ce82f5ba10dca5087339704ffd0fa
  Author: Claude Paroz 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/template/loader_tags.py

  Log Message:
  ---
  Fixed #19846 -- Optimized a dict of lists in BlockContext class

Thanks Curtis Maloney for the report and the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 88c726: Skipped a test on Oracle

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 88c726bea0436a404c751cb497e7981b68e74383
  
https://github.com/django/django/commit/88c726bea0436a404c751cb497e7981b68e74383
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M tests/regressiontests/generic_relations_regress/tests.py

  Log Message:
  ---
  Skipped a test on Oracle


  Commit: f565c6f9994b2559a5164dc709a926eac7ebd5fe
  
https://github.com/django/django/commit/f565c6f9994b2559a5164dc709a926eac7ebd5fe
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M tests/regressiontests/inspectdb/tests.py

  Log Message:
  ---
  Marked a test as expected failure. Refs #19884


Compare: https://github.com/django/django/compare/ce094e570e0f...f565c6f9994b

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

[Django]

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"f565c6f9994b2559a5164dc709a926eac7ebd5fe"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f565c6f9994b2559a5164dc709a926eac7ebd5fe"
 Marked a test as expected failure. Refs #19884
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 #19883 is a duplicate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19883: Inconsistent parameter substitution in cursor wrappers

[Django]

#19883: Inconsistent parameter substitution in cursor wrappers
-+-
 Reporter:  xi@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 I think it's a duplicate of #9055, or at least closely related.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 251f34: [1.5.x] Fixed Oracle regression in last_executed_q...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 251f345db68278547fae520632765dc229a02a18
  
https://github.com/django/django/commit/251f345db68278547fae520632765dc229a02a18
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/db/backends/oracle/base.py

  Log Message:
  ---
  [1.5.x] Fixed Oracle regression in last_executed_query() with unicode strings

The regression was likely caused by the fix in #19606 which adjusted
Oracle's unicode detection, though it seems this would have been an
issue in some configurations even before.

Backpatch of ce094e570e0ff085b88b2303e25124331f558e45



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ce094e: Fixed Oracle regression in last_executed_query() w...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ce094e570e0ff085b88b2303e25124331f558e45
  
https://github.com/django/django/commit/ce094e570e0ff085b88b2303e25124331f558e45
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/db/backends/oracle/base.py

  Log Message:
  ---
  Fixed Oracle regression in last_executed_query() with unicode strings

The regression was likely caused by the fix in #19606 which adjusted
Oracle's unicode detection, though it seems this would have been an
issue in some configurations even before.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17541: Unexpected ForeignKey Behavior with self.pk == None

[Django]

#17541: Unexpected ForeignKey Behavior with self.pk == None
-+-
 Reporter:  sheats   |Owner:  anonymous
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"8a99d718f7db2d018a37f78a8e5639ff2d1d2aa8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8a99d718f7db2d018a37f78a8e5639ff2d1d2aa8"
 [1.5.x] Fixed empty strings + to_field regression on Oracle

 Querying the reverse side of nullable to_field relation, where both
 sides can contain null values resulted in incorrect results. The reason
 was not detecting '' as NULL.

 Refs #17541, backpatch of 09fcb70c804b76fccc8fc0ac545873e5ab30c00a.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 8a99d7: [1.5.x] Fixed empty strings + to_field regression ...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 8a99d718f7db2d018a37f78a8e5639ff2d1d2aa8
  
https://github.com/django/django/commit/8a99d718f7db2d018a37f78a8e5639ff2d1d2aa8
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/db/models/fields/related.py
M tests/regressiontests/many_to_one_regress/tests.py

  Log Message:
  ---
  [1.5.x] Fixed empty strings + to_field regression on Oracle

Querying the reverse side of nullable to_field relation, where both
sides can contain null values resulted in incorrect results. The reason
was not detecting '' as NULL.

Refs #17541, backpatch of 09fcb70c804b76fccc8fc0ac545873e5ab30c00a.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 09fcb7: Fixed empty strings + to_field regression on Oracl...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 09fcb70c804b76fccc8fc0ac545873e5ab30c00a
  
https://github.com/django/django/commit/09fcb70c804b76fccc8fc0ac545873e5ab30c00a
  Author: Anssi Kääriäinen 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/db/models/fields/related.py
M tests/regressiontests/many_to_one_regress/tests.py

  Log Message:
  ---
  Fixed empty strings + to_field regression on Oracle

Querying the reverse side of nullable to_field relation, where both
sides can contain null values resulted in incorrect results. The reason
was not detecting '' as NULL.

Refs #17541



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17541: Unexpected ForeignKey Behavior with self.pk == None

[Django]

#17541: Unexpected ForeignKey Behavior with self.pk == None
-+-
 Reporter:  sheats   |Owner:  anonymous
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"09fcb70c804b76fccc8fc0ac545873e5ab30c00a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="09fcb70c804b76fccc8fc0ac545873e5ab30c00a"
 Fixed empty strings + to_field regression on Oracle

 Querying the reverse side of nullable to_field relation, where both
 sides can contain null values resulted in incorrect results. The reason
 was not detecting '' as NULL.

 Refs #17541
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

[Django]

#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-+-
 Reporter:  anonymous|Owner:  aashu_dwivedi
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sprintdec01  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carbonXT):

 Extending the 'blank' kwarg as described here
 https://code.djangoproject.com/ticket/4136#comment:24 would cover this
 case as well by doing:

 {{{
 some_ip = models.IPAddressField(blank=models.SET_NULL, null=True)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14571: Update jQuery

[Django]

#14571: Update jQuery
--+
 Reporter:  robhudson |Owner:  dArignac
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.2
 Severity:  Normal|   Resolution:  fixed
 Keywords:  jquery sprintnov13| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+

Comment (by Claude Paroz ):

 In [changeset:"60fff6fc9496c7c851182dd6ebac10bb011be2ba"]:
 {{{
 #!CommitTicketReference repository=""
 revision="60fff6fc9496c7c851182dd6ebac10bb011be2ba"
 Documented jQuery upgrade

 Refs #14571.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 60fff6: Documented jQuery upgrade

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 60fff6fc9496c7c851182dd6ebac10bb011be2ba
  
https://github.com/django/django/commit/60fff6fc9496c7c851182dd6ebac10bb011be2ba
  Author: Claude Paroz 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M docs/ref/contrib/admin/index.txt
M docs/releases/1.6.txt

  Log Message:
  ---
  Documented jQuery upgrade

Refs #14571.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19880: form-wizard initial data example is wrong

[Django]

#19880: form-wizard initial data example is wrong
-+-
 Reporter:  almalki  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form-wizard  | Triage Stage:  Accepted
  formwizard wizard  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by carljm):

 #19886 was a duplicate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19886: documentation: FormWizard.as_view() does not have the attribute get_form()

[Django]

#19886: documentation: FormWizard.as_view() does not have the attribute 
get_form()
---+--
 Reporter:  gandalf013@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Thanks for the report! This is a duplicate of #19880.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19886: documentation: FormWizard.as_view() does not have the attribute get_form()

[Django]

#19886: documentation: FormWizard.as_view() does not have the attribute 
get_form()
---+
 Reporter:  gandalf013@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The [https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-
 wizard/#providing-initial-data-for-the-forms documentation] for form
 wizards has this example:

 {{{
 >>> from myapp.forms import ContactForm1, ContactForm2
 >>> from myapp.views import ContactWizard
 >>> initial = {
 ... '0': {'subject': 'Hello', 'sender': 'u...@example.com'},
 ... '1': {'message': 'Hi there!'}
 ... }
 >>> wiz = ContactWizard.as_view([ContactForm1, ContactForm2],
 initial_dict=initial)
 >>> form1 = wiz.get_form('0')
 >>> form2 = wiz.get_form('1')
 >>> form1.initial
 {'sender': 'u...@example.com', 'subject': 'Hello'}
 >>> form2.initial
 {'message': 'Hi there!'}
 }}}

 The above example (with the definitions of `ContactForm1`, `ContactForm2`,
 and `ContactWizard` from earlier) fails:

 {{{
 AttributeError: 'function' object has no attribute 'get_form'
 }}}

 It seems like the example assumes that `as_view()` should return an
 instance of `ContactWizard`, whereas it actually returns a 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19885: Make all testing tools importable from django.test

[Django]

#19885: Make all testing tools importable from django.test
--+
 Reporter:  akaariai  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 We backported unittest2 into the Django codebase as
 `django.utils.unittest` because it is only available in the standard
 library of Python 2.7+. When we drop support for Python 2.6, we will get
 rid of `django.utils.unittest` entirely. I wouldn't have any problem with
 importing a common utility like `skipIf` into `django/test/__init__.py` in
 parallel with the other skip-related utilities imported there; that will
 actually reduce the amount of search and replace we have to do when we
 switch from using `django.utils.unittest` to stdlib `unittest`.

 Similarly I'd be fine importing `override_settings` (and anything else
 from `django.test.utils` that is commonly used) into
 `django/test/__init__.py`.

 I don't feel quite so good about doing that with `parse_html`; HTML-
 parsing is a separate niche that many tests don't need, it makes sense to
 me to keep that segregated in `django.test.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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19885: Make all testing tools importable from django.test

[Django]

#19885: Make all testing tools importable from django.test
+
   Reporter:  akaariai  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Currently it is nearly impossible to remember which module has which
 testing item. For example:
   - expectedFailure, skipUnlessDBFeature, ... is from django.test
   - skipIf is from django.utils.unittest
   - override_setting is from django.test.utils
   - parse_html from django.test.html

 I can't remember where to import these. I will always do a git grep in the
 test directory to see the correct import location. I would like to be able
 to import everything from django.test. Or at least django.utils.unittest.*
 + override_settings.

 Is there some reason for the current split?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19884: Inspectdb on Oracle doesn't produce correct field types

[Django]

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.4
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 The test inspectdb.test_field_types() has multiple errors, at least:
   - CharField lengths not correctly inspected (returns double the length
 of generated field)
   - FloatField not correctly inspected (returns DecimalField with
 max_digits=-127)
   - DateTimeField is inspected as TimeField

 Getting all these to work correctly will be somewhat hard. So, the
 suggested short-term fix is to just mark the test as expectedFailure on
 Oracle. Inspectdb isn't high-priority as the output should be hand-edited
 in any case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19883: Inconsistent parameter substitution in cursor wrappers

[Django]

#19883: Inconsistent parameter substitution in cursor wrappers
-+-
 Reporter:  xi@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Thanks for the report!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19883: Inconsistent parameter substitution in cursor wrappers

[Django]

#19883: Inconsistent parameter substitution in cursor wrappers
--+
 Reporter:  xi@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The following script produces different results with different values of
 `DEBUG` setting and the database backend:

 {{{
 from django.db import connections
 from django.db.utils import DEFAULT_DB_ALIAS
 connection = connections[DEFAULT_DB_ALIAS]
 cursor = connection.cursor()
 cursor.execute("SELECT 'test' LIKE '%st'")
 print cursor.fetchone()
 }}}

 Correct output with `DEBUG=False` and `ENGINE=postgresql_psycopg2`:
 {{{
 (True,)
 }}}

 Correct output with `DEBUG=False` and `ENGINE=mysql`:
 {{{
 (1L,)
 }}}

 Incorrect output with `DEBUG=False` and `ENGINE=sqlite3`:
 {{{
 (0,)
 }}}

 Traceback with `DEBUG=True` and `ENGINE=postgresql_psycopg2`:
 {{{
 Traceback (most recent call last):
   File "bug.py", line 9, in 
 cursor.execute("SELECT 'test' LIKE '%st'")
   File "/home/xi/lib/python2.7/site-packages/django/db/backends/util.py",
 line 40, in execute
 return self.cursor.execute(sql, params)
   File "/home/xi/lib/python2.7/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 52, in
 execute
 return self.cursor.execute(query, args)
 IndexError: tuple index out of range
 }}}

 Traceback with `DEBUG=True` and `ENGINE=mysql`:
 {{{
 Traceback (most recent call last):
   File "bug.py", line 9, in 
 cursor.execute("SELECT 'test' LIKE '%st'")
   File "/home/xi/lib/python2.7/site-packages/django/db/backends/util.py",
 line 40, in execute
 return self.cursor.execute(sql, params)
   File "/home/xi/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 114, in execute
 return self.cursor.execute(query, args)
   File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 159, in
 execute
 query = query % db.literal(args)
 TypeError: not enough arguments for format string
 }}}

 Traceback with `DEBUG=True` and `ENGINE=sqlite3`:
 {{{
 Traceback (most recent call last):
   File "bug.py", line 9, in 
 cursor.execute("SELECT 'test' LIKE '%st'")
   File "/home/xi/lib/python2.7/site-packages/django/db/backends/util.py",
 line 44, in execute
 sql = self.db.ops.last_executed_query(self.cursor, sql, params)
   File "/home/xi/lib/python2.7/site-
 packages/django/db/backends/__init__.py", line 614, in last_executed_query
 return smart_unicode(sql) % u_params
 TypeError: not enough arguments for format string
 }}}

 Python DB API does not specify when to perform parameter substitution, but
 it appears all database drivers that use pyformat parameter style follow
 the same rules:

 1. If `cursor.execute(sql)` is called with one parameter, no parameter
 substitution is performed.
 2. If `cursor.execute(sql, params)` is called with two parameters,
 placeholder symbols are replaced with escaped parameter values.

 I'd expect Django cursor wrappers to respect these rules, or at least be
 consistent.  Currently, `django.db.backends.CursorDebugWrapper` and
 `django.db.backends.sqlite3.SQLiteCursorWrapper` violate these
 conventions.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

[Django]

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  utf8mb4 mysql|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * type:  Uncategorized => New 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19507: django.db doesn't wrap / replace psycopg2.InterfaceError

[Django]

#19507: django.db doesn't wrap / replace psycopg2.InterfaceError
-+-
 Reporter:  pitrou   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * type:  Uncategorized => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18207: concrete inheritence, mysql defer bug

[Django]

#18207: concrete inheritence, mysql defer bug
-+-
 Reporter:  leftmoose|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * type:  Uncategorized => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16739: field clash not detected beyond parent

[Django]

#16739: field clash not detected beyond parent
-+-
 Reporter:  Leo  |Owner:  swcisel
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * type:  Uncategorized => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17695: model grandchild joins to top instead of the middle first

[Django]

#17695: model grandchild joins to top instead of the middle first
-+-
 Reporter:  phowe|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * type:  Uncategorized => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16508: Provide real support for virtual fields

[Django]

#16508: Provide real support for virtual fields
-+-
 Reporter:  vzima|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * type:  Uncategorized => New 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13198: exclude() bug when used with Q() objects

[Django]

#13198: exclude() bug when used with Q() objects
-+-
 Reporter:  mucisland|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  exclude Q|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * type:  Uncategorized => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Django]

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

 * cc: reinout@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by julien):

 Replying to [comment:68 gabbork]:
 > hi, will you include this new feature in next 1.5 django release?

 1.5 has been in feature-freeze mode since the first release candidate came
 out some weeks ago. I'm really hoping to have it included in 1.6 though.
 I'm planning to wrap up the patch this weekend during the worldwide
 sprint, and then I'll be seeking feedback from users to make sure we get
 the user experience right.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19880: form-wizard initial data example is wrong

[Django]

#19880: form-wizard initial data example is wrong
-+-
 Reporter:  almalki  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form-wizard  | Triage Stage:  Accepted
  formwizard wizard  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16649: Models.save() refactoring: check updated rows to determine action

[Django]

#16649: Models.save() refactoring: check updated rows to determine action
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 Thanks for the comments! The Finnish dialect of English has special
 grammar...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19879: have 'findstatic' say where it is searching

[Django]

#19879: have 'findstatic' say where it is searching
-+
 Reporter:  ccurvey  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.5-rc-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

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


Comment:

 Seems useful to me.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19878: Not all class based views push self.kwargs to context

[Django]

#19878: Not all class based views push self.kwargs to context
-+-
 Reporter:  void |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

 * needs_docs:   => 0
 * stage:  Unreviewed => Design decision needed
 * type:  Bug => New feature
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Setting this DDN pending comment from someone who uses class-based views.
 Seems like a new feature rather than a bug, in any case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19876: Using a staticmethod for a FileField's upload_to attribute doesn't work

[Django]

#19876: Using a staticmethod for a FileField's upload_to attribute doesn't work
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5-rc-1
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  filefield upload_to  |  Unreviewed
  staticmethod   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 I don't think there's anything Django can do about this, it's just how
 staticmethods (and class bodies) work in Python. There's rarely a good
 reason for using a staticmethod in Python anyway, and the given example
 certainly isn't: a function within a class that takes an instance of that
 class is just a regular method, so why not make it one?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 The patch isn't good enough yet. Mainly, the in_negated flag for
 build_filter() doesn't work properly. It is used for two things, first for
 answering if the filter needs subquery, and in this case the answer is yes
 if the three contains negated=True at any point, and also for IS NULL
 checking, and in this case the answer comes from the current state of the
 negation, that is the IS NULL check is needed only if the path contains
 odd amount of NOTs, otherwise they will cancel each other.

 In addition I have been playing back-and-forth with add_filter() and
 build_filter(). The build_filter() naming isn't good, it alters the
 query's joins but the name suggests it just builds the filter condition.
 So, for that reason too this patch needs still improvement.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19326: Add a first method to the QuerySet

[Django]

#19326: Add a first method to the QuerySet
-+-
 Reporter:  Wim Feijen   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  first|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Ready for checkin => Design decision needed


Comment:

 I'm setting this to DDN. If these methods were added, then the API would
 be confusing. .latest() vs .last() and .earliest() vs .first() will be
 confusing.

 I still think it would be nice to have some way to get None instead of
 DoesNotExist if the None is expected, not exceptional value. However
 adding anything that is confusing is a bad idea.

 Another API idea: .default(None).get(...), .default(someobj).latest() or
 .default(None).order_by('somecol')[0] could all make the ORM return None
 or any other given value instead of DoesNotExist. Does this sound
 sensible? Naming is of course tentative, for example .default_on_empty()
 could be better if somewhat long...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19874: Add id to element in CheckboxSelectMultiple

[Django]

#19874: Add id to  element in CheckboxSelectMultiple
--+
 Reporter:  l3on  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Seems reasonable to me; the id is currently only used to construct per-
 option numbered IDs, it makes sense that the base ID would be applied to
 the container.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19871: Extend ResetPasswordTokenGenerator to handle arbitraty tokens

[Django]

#19871: Extend ResetPasswordTokenGenerator to handle arbitraty tokens
---+--
 Reporter:  cgenie@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Thanks for the report! I don't think the proposed patch makes sense; the
 specific user data that is hashed in `_make_token_with_timestamp` is
 sensible for the password-reset (as outlined in the comment) but not
 necessarily for some other use; just changing the key salt doesn't
 magically make this a one-size-fits-all token generator. If you want to
 reuse some of this code, you can subclass and override the
 `_make_token_with_timestamp` method, and you probably should be doing that
 anyway.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19861: Improve connection._dirty flag handling

[Django]

#19861: Improve connection._dirty flag handling
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19854: There should be an explicit flag to turn on/off Selenium tests in Django's own test suite

[Django]

#19854: There should be an explicit flag to turn on/off Selenium tests in 
Django's
own test suite
---+
 Reporter:  carljm |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19851: 500 page suggests to contact non-existant email address

[Django]

#19851: 500 page suggests to contact non-existant email address
-+-
 Reporter:  nkuttler |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  *.djangoproject.com  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * status:  new => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19882: Forloop with a filter that has an argument containing whitespace raises a TemplateSyntaxError

[Django]

#19882: Forloop with a filter that has an argument containing whitespace raises 
a
TemplateSyntaxError
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  forloop filter   | Triage Stage:  Accepted
  TemplateSyntaxError|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"f13bfbec70e096f230e3dcda88a2cb215e7f8899"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f13bfbec70e096f230e3dcda88a2cb215e7f8899"
 Fixed #19882 -- Smarter tokenizing of {% for %} tag arguments.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f13bfb: Fixed #19882 -- Smarter tokenizing of {% for %} ta...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f13bfbec70e096f230e3dcda88a2cb215e7f8899
  
https://github.com/django/django/commit/f13bfbec70e096f230e3dcda88a2cb215e7f8899
  Author: Baptiste Mispelon 
  Date:   2013-02-22 (Fri, 22 Feb 2013)

  Changed paths:
M django/template/defaulttags.py
M tests/regressiontests/templates/tests.py

  Log Message:
  ---
  Fixed #19882 -- Smarter tokenizing of {% for %} tag arguments.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19847: add a "step_failure" method on WizardView

[Django]

#19847: add a "step_failure" method on WizardView
-+-
 Reporter:  mothsART |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.formtools|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  validate wizardview  | Triage Stage:  Design
  log|  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 I'm going to put this into DDN state pending an opinion from someone more
 familiar with the form wizard; I've never used it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19842: annotate()-based solution to distinct and order_by problem

[Django]

#19842: annotate()-based solution to distinct and order_by problem
--+
 Reporter:  jogwen|Owner:  dfanders
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 I think it's probably true that many cases of people trying to use
 `distinct` and `order_by` on related fields together would be solved by
 `annotate`. It wouldn't hurt to mention `annotate` in that note.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19838: Deleting a protected fk relationships throws error 500 when deleting inlines

[Django]

#19838: Deleting a protected fk relationships throws error 500 when deleting
inlines
---+
 Reporter:  rafadev|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19827: Exception reraise in defaulttags shoud keep stacktrace

[Django]

#19827: Exception reraise in defaulttags shoud keep stacktrace
-+
 Reporter:  Kronuz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * component:  Uncategorized => Template system
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19825: URLValidator

[Django]

#19825: URLValidator
-+-
 Reporter:  agestart@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  urlvalidator url | Triage Stage:
  field validator|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 A valid URL cannot have a space in it, it must be encoded as `%20`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19820: Make loaddata error messages less cryptic

[Django]

#19820: Make loaddata error messages less cryptic
-+-
 Reporter:  bigfudge |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Core |   Resolution:  needsinfo
  (Serialization)| Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Closing needsinfo pending clarification of whether the better error
 messages are really needed at deserialization or database-insert, and an
 example clearly demonstrating the problem that the proposed fix would
 ameliorate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19816: Assigning a QS to a M2M relation that was generated from that M2M relation clears both the QS and the relation

[Django]

#19816: Assigning a QS to a M2M relation that was generated from that M2M 
relation
clears both the QS and the relation
-+-
 Reporter:  jedediah |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Yes, because the queryset isn't evaluated until after the existing m2m
 values are cleared, meaning it evaluates to an empty queryset. Definitely
 a bug. Thanks for the report!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19806: django_bash_completion clobbers upstream completion of ‘python’

[Django]

#19806: django_bash_completion clobbers upstream completion of ‘python’
-+-
 Reporter:  andersk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Management commands)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, this is quite unfriendly.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19801: input_formats sample codes missing the required parenthesis

[Django]

#19801: input_formats sample codes missing the required parenthesis
--+
 Reporter:  leandron85@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 I don't have a strong opinion either, but I'd lean slightly towards
 explicitly making it a list, at least in the first example where we are
 showing the default value. I think the opening bracket could be placed at
 the beginning of the first line, rather than on its own line. Also:
 brackets, not parens. If we're calling it a list, let's make it a list,
 not a tuple.

 (Anyone with a strong opinion on the aesthetics here, feel free to
 override me and close this wontfix, I'm just trying to get it off the
 unreviewed list :-) )

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19882: Forloop with a filter that has an argument containing whitespace raises a TemplateSyntaxError

[Django]

#19882: Forloop with a filter that has an argument containing whitespace raises 
a
TemplateSyntaxError
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  forloop filter   | Triage Stage:  Accepted
  TemplateSyntaxError|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19872: cached_property doesn't behave properly when accessed through the class

[Django]

#19872: cached_property doesn't behave properly when accessed through the class
--+
 Reporter:  simonpercivall|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by fhahn):

 * version:  1.4 => master
 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19784: Custom urlconf reset too early

[Django]

#19784: Custom urlconf reset too early
-+--
 Reporter:  pakal|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  urlconf request  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19784: Custom urlconf reset too early

[Django]

#19784: Custom urlconf reset too early
-+--
 Reporter:  pakal|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  urlconf request  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by carljm):

 Thanks for the report; closing as duplicate of #19541.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19541: Reversing URLs in response middleware or streamed responses won't use per-request urlconf (was: Reversing URLs in streamed responses (probably) doesn't work)

[Django]

#19541: Reversing URLs in response middleware or streamed responses won't use 
per-
request urlconf
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by carljm):

 #19784 reports the same problem wrt response middleware.

 I don't think it's quite accurate to say that "reversing URLs isn't
 possible any longer"; it just won't use a per-request custom URLconf.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19781: Documentation on Django Comments moderation emails doesn't match actual behavior

[Django]

#19781: Documentation on Django Comments moderation emails doesn't match actual
behavior
--+
 Reporter:  mikeshultz|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.comments  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

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


Comment:

 Thanks for the report! The title here says the behavior contradicts the
 documentation; I don't think that's true, the documentations says the
 email will be sent "to site staff", which is an accurate description of
 `settings.MANAGERS`, if not very specific.

 I think it's reasonable to be able to control who gets these emails at a
 level specific to `contrib.comments`, though I doubt that we'd want to
 query the database for this information.

 On a different not, I really think `contrib.comments` is a prime candidate
 for spinning out into a standalone project. There's nothing about it that
 requires being in contrib, and it's not all that well cared for there.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19763: LocaleMiddleware should check for supported languages in settings.LANGUAGE_CODE too

[Django]

#19763: LocaleMiddleware should check for supported languages in
settings.LANGUAGE_CODE too
--+
 Reporter:  kozz  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  locale| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

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


Comment:

 Seems like the workaround here is simple enough - why not just set
 `LANGUAGE_CODE` to "en"?

 That said, given that `LANGUAGES` is documented as "restrict language
 selection to a subset of the Django-provided languages", it seems
 reasonable that Django shouldn't redirect to a language code outside of
 that set.

 I'm not an expert on the localization stuff, though, so other core devs:
 feel free to reverse this decision if I'm way off base :-)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19758: Password reset form should not leak information

[Django]

#19758: Password reset form should not leak information
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 I know this has been debated in the past, but I agree that the default
 behavior should be safe with respect to both security and confidentiality
 requirements. If some people want a "friendlier" password reset and don't
 care about these requirements, we can document an easy path to providing
 different responses depending whether the email address is enrolled.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19747: Admin save of non-default database model fails when model contains unique fields

[Django]

#19747: Admin save of non-default database model fails when model contains 
unique
fields
-+-
 Reporter:  jay@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  multi-database   | Triage Stage:  Accepted
  admin save |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19721: Django admin allows filtering using the field lookups such as "in", but it is impossible to include a value that contains a comma

[Django]

#19721: Django admin allows filtering using the field lookups such as "in", but 
it
is impossible to include a value that contains a comma
---+
 Reporter:  aruseni|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 Not sure if the backslash-escape is a good idea, or if we just need to
 provide a way to easily subclass the standard ListFilter and replace just
 the separator character (and then document that). Either way, it should be
 easier to filter on values including a comma.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19716: Support microsecond precision in MySQL ORM DateTimeField

[Django]

#19716: Support microsecond precision in MySQL ORM DateTimeField
-+-
 Reporter:  erik@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19710: ModelAdmin exclude behaviour not consistent with ModelAdmin behaviour

[Django]

#19710: ModelAdmin exclude behaviour not consistent with ModelAdmin behaviour
---+
 Reporter:  rafales|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19671: Model field option "validators" not working with ManyToManyField

[Django]

#19671: Model field option "validators" not working with ManyToManyField
-+-
 Reporter:  fabio@…  |Owner:  fhahn
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  validators   | Triage Stage:  Accepted
  ManyToManyField|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 Not immediately obvious to me whether this will be reasonably fixable or
 not, but if not then a documentation fix is still clearly required.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches

[Django]

#19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches
-+
 Reporter:  matthewwithanm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19636: inhibit signals to modify some field on tests

[Django]

#19636: inhibit signals to modify some field on tests
---+--
 Reporter:  oscaracena@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  signals, tests | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by oscaracena@…):

 Ok, no problem. Thanks for reviewing! :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19658: Login redirects use wrong URL when application doesn't live on web server root

[Django]

#19658: Login redirects use wrong URL when application doesn't live on web 
server
root
-+--
 Reporter:  david.reitter@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  worksforme
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by carljm):

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


Comment:

 Thanks for the report! In Django 1.5 hardcoding is no longer the best one
 can do; these `*_URL` settings now accept reversable url names or view
 function names (see e.g.
 https://docs.djangoproject.com/en/dev/ref/settings/#login-redirect-url),
 which should be portable and return correct results (presuming url-
 reversing generally works in your deployment scenario).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19636: inhibit signals to modify some field on tests

[Django]

#19636: inhibit signals to modify some field on tests
---+--
 Reporter:  oscaracena@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  signals, tests | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Thanks for the suggestion! I can see that there are some cases where this
 would be useful; I also think it would invite abuse. In most cases I think
 this is better handled by making the signal handler smarter (or not using
 a signal at all). And regardless, this decorator can easily live outside
 of Django core, I don't think it's a sufficiently common pattern to
 warrant inclusion in core.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19621: templates suppress TypeErrors from comparisons

[Django]

#19621: templates suppress TypeErrors from comparisons
-+--
 Reporter:  leftmoose|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by carljm):

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


Comment:

 Thanks for the report!

 In general, the philosophy of the Django template language is to suppress
 errors, on the theory that template designers should not be able to cause
 crashes. So I think this is consistent with how the rest of the template
 language operates.

 (Personally, I don't buy the rationale for that philosophy, as it is
 always possible for a template designer to make a site effectively non-
 functional one way or another. But changing the approach of the entire
 template language to error-suppression would require a comprehensive
 review of current behavior and a proposal on the mailing list; it
 shouldn't happen piecemeal via tickets for individual cases.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19882: Forloop with a filter that has an argument containing whitespace raises a TemplateSyntaxError

[Django]

#19882: Forloop with a filter that has an argument containing whitespace raises 
a
TemplateSyntaxError
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  forloop filter   | Triage Stage:  Accepted
  TemplateSyntaxError|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Reproduced; this is clearly a bug. Thanks for the report!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19866: SuspiciousOperation should not be answered with HTTP 500

[Django]

#19866: SuspiciousOperation should not be answered with HTTP 500
---+
 Reporter:  tiwoc  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by carljm):

 Replying to [comment:9 tiwoc]:
 > I want to work around this issue until 1.6 is here. Is defining a
 logging filter that removes `SuspiciousOperation` exceptions (along the
 lines of the example for `CallbackFilter` from the
 
[https://docs.djangoproject.com/en/1.4/topics/logging/#django.utils.log.CallbackFilter
 logging docs]) the best way to do this?

 Yep, that's the right approach.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19881: Document that get_next/previous_by_FOO uses default manager

[Django]

#19881: Document that get_next/previous_by_FOO uses default manager
--+
 Reporter:  jtiai |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Also, thanks for the report and for providing a demonstration test case! I
 would have found it much harder to understand the report without the
 testcase. In future, though, it's easiest to work with a test case if
 provided as a patch file against Django's own test suite (master branch)
 rather than as a zipped project.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19881: Document that get_next/previous_by_FOO uses default manager (was: get_next/previous_by_FOO doesn't work properly with multiple managers)

[Django]

#19881: Document that get_next/previous_by_FOO uses default manager
--+
 Reporter:  jtiai |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Model instances don't have a memory of how they were queried for, and the
 only way to "fix" this would be to add such a memory. I think the
 downsides of adding that additional state to model instances far outweighs
 the benefit of fixing this behavior; it would require much stronger
 coupling between both managers and the querysets they return, and
 querysets and the instances they query for. `get_next` and `get_previous`
 operate with respect to the entire set of model instances of that type,
 not some arbitrarily narrowed set. If you need them to operate with
 respect to a narrowed set, you can pass additional filter arguments to
 them.

 It would be worth documenting this more clearly, however; accepting and
 changing the component to documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19252: Install from wheel package

[Django]

#19252: Install from wheel package
--+
 Reporter:  Alex Morega   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * status:  closed => new
 * resolution:  invalid =>
 * severity:  Release blocker => Normal


Comment:

 The wheel PEP is now accepted, and pip will soon have support AFAIK.

 Regardless, comment 5 is correct that we jump through way too many hoops
 in our setup.py in order to try to trick distutils into handling
 `data_files` as if they were `package_data`, and that is the root cause of
 this bug. Instead we should just use `package_data` and solve the problem
 properly.

 I don't believe this is a 1.5 release blocker, though, so re-setting the
 severity to Normal.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15519: Custom SQL location

[Django]

#15519: Custom SQL location
-+-
 Reporter:  vzima|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.2
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by vzima):

 Created a pull request on github:
 https://github.com/django/django/pull/747

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19882: Forloop with a filter that has an argument containing whitespace raises a TemplateSyntaxError

[Django]

#19882: Forloop with a filter that has an argument containing whitespace raises 
a
TemplateSyntaxError
--+
 Reporter:|  Owner:  nobody
  bmispelon   | Status:  new
 Type:  Bug   |Version:  master
Component:  Template  |   Keywords:  forloop filter TemplateSyntaxError
  system  |  Has patch:  0
 Severity:  Normal|  UI/UX:  0
 Triage Stage:|
  Unreviewed  |
Easy pickings:  0 |
--+
 In a template, when looping over a variable that has a filter with an
 argument containing whitespace, a `TemplateSyntaxError` will be thrown.

 Here's a small test case to reproduce the issue (the first template fails
 while the other two work as expected):
 {{{#!python
 from django.template import Template, Context

 for tpl in [
 '{% for x in ""|add:"a b c" %}{{ x }}{% endfor %}', # Doesn't work
 '{% with v=""|add:"a b c" %}{% for x in v %}{{ x }}{% endfor %}{%
 endwith %}',
 '{% with v="a b c" %}{% for x in ""|add:v %}{{ x }}{% endfor %}{%
 endwith %}'
 ]:
 s = Template(tpl).render(Context())
 assert s == u'a b c'
 }}}

 Here's the traceback that this produces:
 {{{
 Traceback (most recent call last):
   File "my_script.py", line 8, in 
 s = Template(tpl).render(Context())
   File "/path/to/venv/local/lib/python2.7/site-
 packages/django/template/base.py", line 125, in __init__
 self.nodelist = compile_string(template_string, origin)
   File "/path/to/venv/local/lib/python2.7/site-
 packages/django/template/base.py", line 153, in compile_string
 return parser.parse()
   File "/path/to/venv/local/lib/python2.7/site-
 packages/django/template/base.py", line 278, in parse
 compiled_result = compile_func(self, token)
   File "/path/to/venv/local/lib/python2.7/site-
 packages/django/template/defaulttags.py", line 758, in do_for
 " 'for x in y': %s" % token.contents)
 django.template.base.TemplateSyntaxError: 'for' statements should use the
 format 'for x in y': for x in ""|add:"a b c"
 }}}

 It looks like `token.contents.split()` in the code of the tag gets
 confused by the whitespace and splits the string into too many parts.

 Since the code searches for the "in" keyword from the end (position -2
 since we are not reversed), then it fails.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18213: loaddata should allow empty fixtures

[Django]

#18213: loaddata should allow empty fixtures
---+--
 Reporter:  lsaffre|Owner:  renatooliveira
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by renatooliveira):

 Sorry about the delay, I'll send the patch this week.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19841: Problem in documentation "Writing your first Django app, part 1" with manage.py runserver

[Django]

#19841: Problem in documentation "Writing your first Django app, part 1" with
manage.py runserver
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timo):

 * status:  new => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19874: Add id to element in CheckboxSelectMultiple

[Django]

#19874: Add id to  element in CheckboxSelectMultiple
---+--
 Reporter:  l3on   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timo):

 * needs_better_patch:   => 0
 * component:  Documentation => Forms
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19866: SuspiciousOperation should not be answered with HTTP 500

[Django]

#19866: SuspiciousOperation should not be answered with HTTP 500
---+
 Reporter:  tiwoc  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by tiwoc):

 Sounds good to me!

 I want to work around this issue until 1.6 is here. Is defining a logging
 filter that removes `SuspiciousOperation` exceptions (along the lines of
 the example for `CallbackFilter` from the
 
[https://docs.djangoproject.com/en/1.4/topics/logging/#django.utils.log.CallbackFilter
 logging docs]) the best way to do 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19881: get_next/previous_by_FOO doesn't work properly with multiple managers

[Django]

#19881: get_next/previous_by_FOO doesn't work properly with multiple managers
--+
 Reporter:  jtiai |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Model methods get_next_by_FOO() and get_previous_by_FOO() doesn't honor
 original manager used but uses always default manager (first manager
 declared on a model).

 This might potentially return incorrect data, for example in cases where
 softdelete is used. Default manager would return all objects but normally
 user uses manager that returns only non-deleted objects. In that case
 get_next|pervious_by_FOO would return incorrect data.

 Possible workaround would be using proxy models.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18526: {% with %} template tag shows strange behaviour if TEMPLATE_STRING_IF_INVALID is non-empty.

[Django]

#18526: {% with %} template tag shows strange behaviour if
TEMPLATE_STRING_IF_INVALID is non-empty.
-+-
 Reporter:  gregmuellegger   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  with | Triage Stage:
  TEMPLATE_STRING_IF_INVALID |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gregmuellegger):

 Me neither. I think ``TEMPLATE_STRING_IF_INVALID`` is kind of bad-practice
 debugging. So a +1 for deprecating it. What would be more elegant (but
 outside of django core) would be to have a django-debug-toolbar panel that
 lists all the "invalid" template variables used in the templates of the
 current page. But I don't know if an implementation is sanely possible at
 the moment (if there exist any usefull hooks in the template engine).

 However this would also leave out the debugging of templates that are
 rendered out of the request-response cycle.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by wdoekes):

 * version:  1.0 => master
 * stage:  Accepted => Design decision needed


Comment:

 Ok. I was only partially right.

 (a) Cursor behaviour was inconsistent for the different backends:
 - oracle and sqlite always got interpolation
 - mysql and postgres only got interpolation if (DEBUG or len(params)>0)

 (b) Changing `()` to `None` would be the fix that breaks DEBUG and not
 PRODUCTION, not the other way around.

 

 I updated claudep's patch to make it consistent: percent signs only need
 escaping if params is supplied (and not `None`).

 Tested with: mysql and sqlite. I also tested that passing None to postgres
 gives no interpolation, so that should work.

 Unfortunately, this changes things for everyone using parameter-less
 queries. (Except mysql and postgres users in non-DEBUG.) So I'm switching
 it to design decision needed. (Apologies in advance if I'm not supposed to
 do that.)

 Regards,
 Walter Doekes

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19880: form-wizard initial data example is wrong

[Django]

#19880: form-wizard initial data example is wrong
---+---
 Reporter:  almalki|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:  form-wizard formwizard wizard
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+---
 In this [https://docs.djangoproject.com/en/1.4/ref/contrib/formtools/form-
 wizard/#providing-initial-data-for-the-forms example] there is a small
 error, basically it is calling as_view and then call methods on the
 returned function.


 {{{
 >>> wiz = ContactWizard.as_view([ContactForm1, ContactForm2],
 initial_dict=initial)
 >>> form1 = wiz.get_form('0')
 }}}

 should be:

 {{{
 >>> wiz = ContactWizard([ContactForm1, ContactForm2],
 initial_dict=initial)
 >>> form1 = wiz.get_form('0')
 }}}


 (assuming {{{ __init__ }}} takes same arguments as as_view)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by gabbork):

 hi, will you include this new feature in next 1.5 django release?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by wdoekes):

 @hlhicks: the point was not that percent signs are a problem. The point
 was that they were treated differently when in DEBUG mode.

 The solution was to enforce string interpolation to be performed in all
 cases, instead of half of the cases. The default parameter should be `()`
 instead of `None`, so `'%%' % ()` would become `'%'`.

 Sure, the default could be `None` too. As long as it doesn't differ
 between DEBUG and PRODUCTION. But you don't want to mess with PRODUCTION,
 so changing the DEBUG is a safe bet.

 

 > For example... cursor.execute("insert into the_table
 > (name, phone, zip) values (?,?,?)",("me","800...","30101"))
 [[br]]
 As for the `db.ops.last_executed_query`, that's just code to aid in
 debugging. The important stuff happens here (in the MySQL case):
 {{{
   File ".../MySQLdb/cursors.py", line 159, in execute
 query = query % db.literal(args)
 }}}
 Where `db.literal` escapes `args` into quoted variants when appropriate.

 Here I could see you might want question marks (`?`) to work, but the web
 has this to say:
 [[br]]
 > Sadly, DBAPI requires a parameter type, but it doesn't specify
 > which. You have to look at the module's paramstyle to determine
 > which. Some DBAPI modules use the qmark style. MySQLdb uses the
 > format style, which unfortunately results in exactly this
 > confusion between parameterisation and string formatting. It's a
 > mess. (bobince@stackoverflow)
 http://www.python.org/dev/peps/pep-0249/#paramstyle
 {{{
 $ grep paramstyle\ = .../MySQLdb/__init__.py
 paramstyle = "format"
 }}}

 

 @gst: re: Search. Yeah. Trac isn't always good at finding what you're
 looking for.

 As for the fix. I believe anyone is allowed to mark bugs as Ready For
 Checkin, when they've tested that the relevant patch applies cleanly to
 trunk and passes its 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.