Re: [Django] #17654: auto_now_add=True column creates IntegrityError if model is saved by specifying an id

[Django]

#17654: auto_now_add=True column creates IntegrityError if model is saved by
specifying an id
-+-
 Reporter:  gtorok@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  auto_now_add,|  Unreviewed
  IntegrityError |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 There isn't any bug if this happens only when there is already an object
 with the same PK in the database. Because now you are not doing an add,
 you are doing an update. I think it works as specified, although I can see
 that this might be a bit confusing. The key here is that the id field's
 value identifies the object, so from Django's point of view you are really
 saving the same object to the DB, not adding a new one.

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

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

[Django] #17655: having a forward option for tickets

[Django]

#17655: having a forward option for tickets
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hey may i know if there is any possibility for providing the forward
 provision for an existing ticket.

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

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

Re: [Django] #16759: Expensive sql.Query cloning

[Django]

#16759: Expensive sql.Query cloning
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm performance  |  Needs documentation:  0
  cloning|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I agree on immutable-by-convention approach to the values in the queryset.
 The only other approach is deepcopy, and we know that can cause some
 problems. A common problematic case would be list of models, where the
 deepcopy would do exactly what it does now - deepcopy the model meta.

 As for testing this, the approach given by lrekucki seems very good. Lets
 use that. One more test case could be the arguments deepcopying. If I am
 not mistaken, if you give the qs a list of models, the deepcopy will go
 "too deep".

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

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

Re: [Django] #16827: validate CSRF token (Check length)

[Django]

#16827: validate CSRF token (Check length)
-+-
 Reporter:  jedie|Owner:  raulcd
 Type:  Bug  |   Status:  assigned
Component:  contrib.csrf |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aashu_dwivedi):

 from the source code i noticed that the method
 {{{
 django.utils.crypto.constant_time_compare
 }}}

 is being used for comparing the request token from the one already present
 in the cookie, since the comparison is already constant time is the length
 checking really 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16827: validate CSRF token (Check length)

[Django]

#16827: validate CSRF token (Check length)
-+-
 Reporter:  jedie|Owner:  raulcd
 Type:  Bug  |   Status:  assigned
Component:  contrib.csrf |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 from the source code i noticed that the method
 {{{
 django.utils.crypto.constant_time_compare
 }}}

 is being used for comparing the request token from the one already present
 in the cookie, since the comparison is already constant time is the length
 checking really 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16759: Expensive sql.Query cloning

[Django]

#16759: Expensive sql.Query cloning
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm performance  |  Needs documentation:  0
  cloning|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 I am -1 on copying arguments on usage. It's useless work mostly always.
 +1 for documenting it and advising against mutating values after using
 them in queryset.

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

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

Re: [Django] #17654: auto_now_add=True column creates IntegrityError if model is saved by specifying an id

[Django]

#17654: auto_now_add=True column creates IntegrityError if model is saved by
specifying an id
-+-
 Reporter:  gtorok@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  auto_now_add,|  Unreviewed
  IntegrityError |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Also, I should add that the Order with id=1 already existed in the db
 (with a valid created_at date) at the time it was saved again. So it's the
 second save() that causes the problem.

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

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

Re: [Django] #17654: auto_now_add=True column creates IntegrityError if model is saved by specifying an id

[Django]

#17654: auto_now_add=True column creates IntegrityError if model is saved by
specifying an id
-+-
 Reporter:  gtorok@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  auto_now_add,|  Unreviewed
  IntegrityError |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 Here is the code section, correctly formatted:
 {{{
 # Order has this field: created_at =
 models.DateTimeField?(auto_now_add=True, null=False)
 o = models.Order(id=1, name="abc")
 o.save()
 IntegrityError: null value in column "created_at" violates not-null
 constraint
 }}}

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

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

[Django] #17654: auto_now_add=True column creates IntegrityError if model is saved by specifying an id

[Django]

#17654: auto_now_add=True column creates IntegrityError if model is saved by
specifying an id
-+-
 Reporter:  gtorok@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.3
  (models, ORM)  |   Keywords:  auto_now_add,
 Severity:  Normal   |  IntegrityError
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 To reproduce, create a new model which has an auto_now_add=True field and
 specify the id. When calling save() the IntegrityError is raised:

 # Order has this field: created_at =
 models.DateTimeField(auto_now_add=True, null=False)
 o = models.Order(id=1, name="abc")
 o.save()
 IntegrityError: null value in column "created_at" violates not-null
 constraint

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

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

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 Which backend are you using? I'm asking because I know MySQL has issues
 with those kind of ids.

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

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

[Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
--+
 Reporter:  sylvain.lebon@…   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When using get_or_create with id=0, django does create an object, but
 doesn't write the id back in the returned object. The object is therefore
 not usable. We should get the new object's id, or at least get an error
 message to prevent using 0 as an id.

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

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

Re: [Django] #16759: Expensive sql.Query cloning

[Django]

#16759: Expensive sql.Query cloning
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm performance  |  Needs documentation:  0
  cloning|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by lrekucki):

 Here's my approach for testing this. I just mocked {{{__deepcopy__}}} in
 the models we want to make sure that are not copied. I didn't debug this
 deep enough to come up with more tests, so if you have any, please tell me
 :)

 I'm +1 on doing clone() instead of deep copying and really like the patch,
 just want to make sure this bug doesn't reappear again. Not sure if we
 should copy the filter arguments (maybe just advice using immutable types
 in the docs). If we do copy, I think we should try copying to a immutable
 type. Then it's safe to share that value between QuerySet copies.

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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
--+
 Reporter:  etianen   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by charettes):

 While this gets fixed I wrote down a snippet that creates permissions
 without modifying django's code base
 http://djangosnippets.org/snippets/2677/.

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

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

Re: [Django] #16862: Admin delete-cascade check doesn't support per-object permissions

[Django]

#16862: Admin delete-cascade check doesn't support per-object permissions
---+
 Reporter:  Kidwind|Owner:
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  permission | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by marw85):

 * owner:  marw85 =>
 * needs_better_patch:  0 => 1
 * status:  assigned => new
 * needs_tests:  1 => 0


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

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

Re: [Django] #17459: Subquery fails across multiple databases

[Django]

#17459: Subquery fails across multiple databases
-+-
 Reporter:  dgouldin |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jdunck):

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


Comment:

 Well, even if the table did exist, you couldn't assume that the result
 would be correct in a multi-db context because it's pretty often the case
 that table A on db-0 has a subset and table B on db-1 has a different
 subset.

 I think the fact that a multi-db query could successfully run quietly on a
 subset of the intended data is the worse bug here.  I agree that list'ing
 the subquery is a fair solution, but first you have to realize that you
 have the problem at all.

 The problem is that the inlined queryset doesn't call db_for_read at all,
 so that the router can't advise the ORM not to use the default/parent-qs's
 DB.

 I agree that inlining is useful, even in a multi-db context, but the child
 qs's router.db_for_read should still get a change to advise and not be
 inlined.

 Reopening - please wontfix again if you disagree.

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

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

Re: [Django] #17006: Document ModelForm's get_form() and get_formsets()

[Django]

#17006: Document ModelForm's get_form() and get_formsets()
--+
 Reporter:  rasca |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  SVN
 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
--+

Comment (by rasca):

 See also #17646

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

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

Re: [Django] #16841: get_changelist_form and get_changelist_formset should be added to the documentation

[Django]

#16841: get_changelist_form and get_changelist_formset should be added to the
documentation
--+
 Reporter:  jordanreiter  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by rasca):

 See also #17646

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

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

Re: [Django] #17646: Create a get_list_filter hook in ModelAdmin

[Django]

#17646: Create a get_list_filter hook in ModelAdmin
---+
 Reporter:  rasca  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by rasca):

 See also #17006 and #16841

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

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

Re: [Django] #17520: write queries on related managers use the db_for_read database

[Django]

#17520: write queries on related managers use the db_for_read database
---+
 Reporter:  tobias |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by lrekucki):

 * component:  Database layer (models, ORM) => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 I don't think this is a bug. Django by default saves the objects to the
 database they we're fetched from. When using a related manager on a
 fetched object, Django assumes you want them fetched from the same DB
 instead of consulting the router (both for read or write, at least that's
 what is currently tested for) as it's the reasonable thing to do in most
 cases.

 If you want to specify another database you can use {{{db_manager()}}}.
 Passing {{{None}}} to it should force the manager to consulting the
 router. That said, this most likely needs better explanation in the docs.

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

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

Re: [Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)


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

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

Re: [Django] #17591: USSocialSecurityNumberField doesn't validate the same when entered without hypens

[Django]

#17591: USSocialSecurityNumberField doesn't validate the same when entered 
without
hypens
-+-
 Reporter:  aaron.l.madison@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor  | Triage Stage:  Accepted
  ussocialsecuritynumberfield|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by lrekucki):

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


Comment:

 Few notes:

 * Python 2.5 (the minimal version supported right now) doesn't have
 "{{{with}}}" by default, you need {{{from __future__ import
 with_statement}}}. It also doesn't have the {{{.format()}}} method, so
 that won't work,
 * The tests are repetitive: you both added a case to the dictionary and a
 method. Just add all invalid cases to the dictionary, to keep it simple,
 * You don't have to write "{{{bool(area == '666')}}}": "{{{area ==
 '666'}}}" is exactly the same. Same for {{{any([])}}} - that just a
 needlesly complicated "{{{or}}}" expression,
 * The {{{zeros_re}}} - imho, there was nothing wrong with the previous
 check for zeroes, no reason to change it for a regexp,
 * Get rid of "_is_all_zeros()", "_raise_invalid", etc. methods. It doesn't
 save typing nor is more DRY, just makes the code longer.

 If you want the "no_hypen" flag included, you also need to update the
 documentation for this field.

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

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

Re: [Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by julien):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks Luke for the report.

 I'm the one who mentioned Windmill in the doc, mainly to replace the
 mention to Twill which itself appears to be a dead project. See the old
 doc: https://docs.djangoproject.com/en/1.3/topics/testing/

 However, I did not test the integration between Windwill and
 `LiveServerTestCase` and if it doesn't work then we should absolutely
 remove that mention from the doc. Therefore I'm marking this ticket as
 release blocker.

 `LiveServerTestCase` was designed to be completely agnostic about what
 testing framework is used. So I tend to think that the issue lies in
 Windmill itself. Windmill is a fairly active project though, so it'd be
 nice if it did all work well (and if we could leave that mention in the
 doc). So I'll reach out to the Windmill maintainers to see if they have
 any thoughts on how to enable that support within their 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17459: Subquery fails across multiple databases

[Django]

#17459: Subquery fails across multiple databases
-+-
 Reporter:  dgouldin |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  wontfix
 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 lrekucki):

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


Comment:

 After thinking about this for a while, I think it's not something Django
 should do implicitly.

 First of all, because this results in some serious performance drawback
 that's hidden in a place you normally wouldn't expect it to be and it
 gives a false impression of us supporting cross-database queries (which we
 don't).

 Second, because it's not always the right thing to do. Taking the (naive)
 example of master-slave configuration from the docs, the fact that the
 router returns different slaves for Bar and Foo, shouldn't prevent Django
 from generating the subquery. As Django has no other way of knowing, which
 dbs contain which tables, we can't assume that the table is or isn't
 there.

 Explicitly using {{{list()}}} fixes the problem and is more explicit about
 performance/memory overhead of the query.

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

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

[Django] #17652: LiveTestServer - we shouldn't advertise support for Windmill (or we should provide some docs)

[Django]

#17652: LiveTestServer - we shouldn't advertise support for Windmill (or we 
should
provide some docs)
-+
   Reporter:  lukeplant  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  1.3
   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  |
-+
 After an hour or more of messing around, I really can't get anything
 helpful out of Windmill (at all, really, but especially in conjunction
 with Django in any kind of automated way)

 The docs for it are pretty bad in terms of structure, so you can't just
 point people to the docs. (e.g: no proper tutorial, the nearest thing to a
 tutorial tells you to use IPython, but support for IPython > 0.10 is
 broken, etc etc.)

 I've tried Windmill's own django support, which appears to be very broken,
 or extremely difficult.

 So we shouldn't send people down the blind alley of using Windmill when we
 really don't support it at all.

 Alternatively, if we can provide some documentation for how to use it -
 equivalent to the Selenium stuff - then we should. If the people who
 worked on this can comment that will help.

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

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

Re: [Django] #17281: AdminErrorHandler silently fails if the log message contains newlines

[Django]

#17281: AdminErrorHandler silently fails if the log message contains newlines
-+-
 Reporter:  russellm |Owner:  marw85
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by cataliniacob):

 * cc: iacobcatalin@… (added)


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

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

Re: [Django] #17651: images not found in http://www.djangobook.com

[Django]

#17651: images not found in http://www.djangobook.com
---+--
 Reporter:  ericooly   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by anonymous):

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


Comment:

 Closing with the same reasoning other similar tickets have een closed:
 This isn't the issue tracker of the Django Book so reports about it and/or
 its web site don't belong here.

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

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

[Django] #17651: images not found in http://www.djangobook.com

[Django]

#17651: images not found in http://www.djangobook.com
---+
 Reporter:  ericooly   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 It appears the images for these pages are no longer in the directory.
 In http://www.djangobook.com/en/2.0/chapter06/
 the image links are broken.
 I tried inspecting the link, and bringing it up in a browser and got a 404
 error :
 for instance :
 http://new-media.djangobook.com/content/en/2.0/chapter06/admin_index.png
 does not appear to be 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5746: Patch to add support for setting email return-path

[Django]

#5746: Patch to add support for setting email return-path
-+-
 Reporter:  wreese@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Mail)  |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  return-path email| Triage Stage:  Design
  mail   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by guettli):

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


Comment:

 related #9214

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

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

Re: [Django] #17474: Problem when the request doesn't have Content-Type.

[Django]

#17474: Problem when the request doesn't have Content-Type.
-+-
 Reporter:  Marcelo Salhab   |Owner:  nobody
  Brogliato  |   Status:  reopened
 Type:  Bug  |  Version:  1.3
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  content-type |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by olau):

 Huh? Is mod_python implementing WSGI? I thought it was using its own
 protocol.

 Why don't you think a one-line bug fix is worth it? Some people may be
 stuck on mod_python for some years to come.

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

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

Re: [Django] #17286: All cache backends need to call its 'close' function

[Django]

#17286: All cache backends need to call its 'close' function
-+-
 Reporter:  jifeng.yin@… |Owner:  gnosek
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by zsiciarz):

 * cc: zsiciarz (added)
 * stage:  Accepted => Ready for checkin


Comment:

 Works fine, RFC'd.

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

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