date:20140903

Re: [Django] #23412: Unable to import django.forms.util.ValidationError

2014-09-03 Thread Django

#23412: Unable to import django.forms.util.ValidationError
---+--
 Reporter:  george_edison  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.7
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 `ValidationError` has to be imoprted from `django.core.exceptions`, and it
 is documented so for some time I think. Of course, you can theoratically
 import various names from each file where it is imported also, but we
 cannot guarantee that the imports will work over time. If the old import
 location were to be documented in a recent documentation version, that
 would be another story.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.891e3912eb45f5175e105a919f3952ab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23411: Typo on download page, says 1.7 requires at minimum 2.6.5

2014-09-03 Thread Django

#23411: Typo on download page, says 1.7 requires at minimum 2.6.5
-+
 Reporter:  gaqzi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 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 claudep):

 Still needs someone to deploy the update.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.0ae4ec046f2439d0c2cf6038eb9b5310%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23411: Typo on download page, says 1.7 requires at minimum 2.6.5

2014-09-03 Thread Django

#23411: Typo on download page, says 1.7 requires at minimum 2.6.5
-+
 Reporter:  gaqzi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 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 Claude Paroz ):

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


Comment:

 In
 [changeset:"e146101c25c37ae47605b5c421ec93459f5aaab6/djangoproject.com"]:
 {{{
 #!CommitTicketReference repository="djangoproject.com"
 revision="e146101c25c37ae47605b5c421ec93459f5aaab6"
 Fixed #23411 -- Updated minimal Python version to 2.7

 Thanks Björn Andersson 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4964b6f8713ae2605a2e2286c6f943bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23413: django.contrib.contenttypes.fields has been remove

2014-09-03 Thread Django

#23413: django.contrib.contenttypes.fields has been remove
---+--
Reporter: neoblackcap|Owner: nobody
Type: Bug| Status: closed
Component: Documentation | Version: 1.7
Severity: Normal | Resolution: worksforme
Keywords: contenttypes | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
---+--
Changes (by bmispelon):

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

Comment:

Hi,

It seems that you're using Django 1.6 but you're referring to the
documentaiton for 1.7.

Make sure you're using the right version (you can switch version on any
page of the documentation by using the little widget at the bottom right
hand corner of the page).

For reference,
https://docs.djangoproject.com/en/1.6/ref/contrib/contenttypes/#id1 does
use `from django.contrib.contenttypes import generic`.

Thanks.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.c432437071294d94c9ec61c71d2f96b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2014-09-03 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  aggregate, annotate  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jbinary):

 * cc: jbinary (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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5a97580a9ecc7bb3df3482f60090d08b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23413: django.contrib.contenttypes.fields has been remove

2014-09-03 Thread Django

#23413: django.contrib.contenttypes.fields has been remove
---+--
 Reporter:  neoblackcap|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.7
 Severity:  Normal |   Keywords:  contenttypes
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 In the document '''The contenttypes framework''', section '''Generic
 relations'''
 the example show
 {{{
 from django.db import models
 from django.contrib.contenttypes.fields import GenericForeignKey
 from django.contrib.contenttypes.models import ContentType
 }}}
 However, {{{ GenericForeignKey }}} only can be import from
 django.contrib.contenttypes.generic

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.8b04d1386adbd6d60dbbe8bb4d30354c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23403: Sitemap bug

2014-09-03 Thread Django

#23403: Sitemap bug
---+--
 Reporter:  igorcc |Owner:  igorcc
 Type:  Bug|   Status:  assigned
Component:  contrib.sitemaps   |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  date utctimetuple  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by igorcc):

 This code works fine in Django 1.6.6
 The error appeared in Django 1.7
 I suppose this error is highly dependent on the type of date_field - see
 info_dict1 in urls.py

 Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.5e32454752ecba784fd2fc2cb5c8c92c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23412: Unable to import django.forms.util.ValidationError

2014-09-03 Thread Django

#23412: Unable to import django.forms.util.ValidationError
---+--
 Reporter:  george_edison  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.7
 Severity:  Normal |   Resolution:
 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 charettes):

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


Comment:

 `django.form.util` used to be defined as a side effect of all the imports
 in `django/forms/__init__.py`.

 Since we don't import this module anymore, to prevent firing
 `DeprecatingWarning`s, it's never assigned as a property to the
 `django.forms` module. You can validate this is the case by trying to
 access `forms.util` once you explicitly imported `django.forms.util`.

 {{{
 Python 2.7.6 (default, Mar 22 2014, 22:59:56)
 [GCC 4.8.2] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from django import forms
 >>> forms.util
 Traceback (most recent call last):
   File "", line 1, in 
 AttributeError: 'module' object has no attribute 'util'
 >>> from django.forms import util
 >>> forms.util
 
 }}}

 Since accessing `django.forms.util` without explicitly importing the
 `util` module used to works only because of import side effects I'm
 tempted to mark this ticket as ''won't fix''. I'm not even sure there's a
 way to lazily expose the `util` module to support your case without
 triggering the deprecating warnings.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.13970eaca3e3263a5cdd01840dd87d7e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23412: Unable to import django.forms.util.ValidationError

2014-09-03 Thread Django

#23412: Unable to import django.forms.util.ValidationError
---+
 Reporter:  george_edison  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Forms  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I ran the following commands on a completely clean installation of Ubuntu
 Server 14.04.1:

 {{{
 apt-get install python-pip
 pip install Django
 }}}

 I then opened the Python interpreter and ran the following commands:

 {{{
 Python 2.7.6 (default, Mar 22 2014, 22:59:56)
 [GCC 4.8.2] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from django import forms
 >>> forms.util.ValidationError
 Traceback (most recent call last):
   File "", line 1, in 
 AttributeError: 'module' object has no attribute 'util'
 }}}

 It would appear that {{{django.forms.util}}} is missing. This is very odd
 since I can confirm that the relevant file does indeed exist:

 {{{
 # cd /usr/local/lib/python2.7/dist-packages/django/forms
 # ls
 extras  formsets.py   forms.pyc models.py   util.pyc   widgets.py
 fields.py   formsets.pyc  __init__.py   models.pyc  utils.py   widgets.pyc
 fields.pyc  forms.py  __init__.pyc  util.py utils.pyc
 }}}

 I have confirmed this error on two other machines running Ubuntu 14.04.
 According to the contents of the file, the module is set to be removed in
 Django 1.9, so it should still work in Django 1.7.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.069b8b513fe3a88f079f5f8215ea4c57%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23395: Clarification on PEP 8 E501: line too long (> 79 characters)

2014-09-03 Thread Django

#23395: Clarification on PEP 8 E501: line too long (> 79 characters)
--+
 Reporter:  nrogers64 |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by timgraham):

 I'm working on the updates in `django/` and I've split up the test updates
 into 3 files. Please claim one by commenting here if you want to work on
 it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7d2dac5282c8d0158e7564fc154c3a31%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23411: Typo on download page, says 1.7 requires at minimum 2.6.5

2014-09-03 Thread Django

#23411: Typo on download page, says 1.7 requires at minimum 2.6.5
-+
 Reporter:  gaqzi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  *.djangoproject.com  |  Version:  1.7
 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 charettes):

 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.a132aeddb6c98005554be4452ee70de3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23411: Typo on download page, says 1.7 requires at minimum 2.6.5

2014-09-03 Thread Django

#23411: Typo on download page, says 1.7 requires at minimum 2.6.5
-+
 Reporter:  gaqzi|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  *.djangoproject.com  |Version:  1.7
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 There's a typo on the download page saying that 2.6 is supported for
 Django 1.7.

 https://www.djangoproject.com/download/

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.312dd1c4f2a669eef94c87807c718e5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23408: Automaticly created migration calls callable for default only once

2014-09-03 Thread Django

#23408: Automaticly created migration calls callable for default only once
+
 Reporter:  Harper04|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 Markush2010):

 * cc: Markush2010 (added)


Comment:

 I wouldn't consider this a bug as the default value is nothing that is
 enforced on database level but inside Django. If you want to have random
 values per row, you need to add a
 [https://docs.djangoproject.com/en/1.7/ref/migration-
 operations/#django.db.migrations.operations.RunPython RunPython operation]
 that updates the value per row.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c83feef5f874a19697daeb2586a77f2c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23410: Backward migrations change overall state rather than reverting single migration

2014-09-03 Thread Django

#23410: Backward migrations change overall state rather than reverting single
migration
-+--
 Reporter:  Markush2010  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 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 collinanderson):

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


Comment:

 marking as unaccepted release blocker to give this attention, as this
 could have data loss issues. It may be we simply need to better document
 the situation.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.2ce883306987d29cd85ed0bc5e3dedae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23410: Backward migrations change overall state rather than reverting single migration

2014-09-03 Thread Django

#23410: Backward migrations change overall state rather than reverting single
migration
-+
Reporter: Markush2010 | Owner: nobody
Type: Bug | Status: new
Component: Migrations |Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0| UI/UX: 0
-+
When rolling back to a previous migration (or more precisely: state),
Django reverts all migrations between the current state and the one that
point in history looking at the linear migration plan. Taking the example
from the tests

(https://github.com/django/django/blob/1a918806ca67e8e4818aeb1c304e4546baab9e4d/tests/migrations/test_graph.py#L47-L50)
and the behavior how South handled backwards migrations, this is somehow
inconsistent and might even lead to data loss. I'd expect nothing to
happen in the example above.

Looking at the more complex example from the tests

(https://github.com/django/django/blob/1a918806ca67e8e4818aeb1c304e4546baab9e4d/tests/migrations/test_graph.py#L101-L104)
I wouldn't expect `c.0001` being rolled back, instead `a.0001`, `a.0002`,
`b.0001` and `c.0001` should still be applied.

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/054.ddc85e265ee3a0aecd1a07d5169f03ad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23395: Clarification on PEP 8 E501: line too long (> 79 characters)

2014-09-03 Thread Django

#23395: Clarification on PEP 8 E501: line too long (> 79 characters)
--+
 Reporter:  nrogers64 |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by EvilDMP):

 See https://groups.google.com/d/msgid/django-developers/8772de23-2970-4b60
 -91ae-f5817f9b2bac%40googlegroups.com.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2e24fdf791f9981c4b18dd34292ec222%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23124: Add touch support for version chooser in documentation

2014-09-03 Thread Django

#23124: Add touch support for version chooser in documentation
-+-
 Reporter:  jarus|Owner:
 Type:   |  adambrenecki
  Cleanup/optimization   |   Status:  assigned
Component:  *.djangoproject.com  |  Version:
 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:  1
-+-

Comment (by evildmp):

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints.

 If you're tackling this ticket, please don't hesitate to ask me for
 guidance if you'd like any, either at the sprints themselves, or here or
 on the Django IRC channels, where I can be found as ''EvilDMP''.

 Note that the codebase for the Django Project website lives at
 https://github.com/django/djangoproject.com/

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5d4382699576d4483952e48c72e28a77%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23281: Add explicit link into OneToOneField.parent_link

2014-09-03 Thread Django

#23281: Add explicit link into OneToOneField.parent_link
--+
 Reporter:  knowledgepoint-devs   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints.

 If you're tackling this ticket, please don't hesitate to ask me for
 guidance if you'd like any, either at the sprints themselves, or here or
 on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.8e11942bad2fa3925d0afd098c8c951d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23305: Models that are imported on app's import time are invisible to makemigrations when the application is relabeld

2014-09-03 Thread Django

#23305: Models that are imported on app's import time are invisible to
makemigrations when the application is relabeld
--+
 Reporter:  rafalp|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7-rc-2
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints.

 If you're tackling this ticket, please don't hesitate to ask me for
 guidance if you'd like any, either at the sprints themselves, or here or
 on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b29cd4002813a1564a83c1a5edc41281%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23307: max_num limits total number of forms, not empty forms

2014-09-03 Thread Django

#23307: max_num limits total number of forms, not empty forms
--+
 Reporter:  velle |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit
 * version:  1.4 => master


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints.

 If you're tackling this ticket, please don't hesitate to ask me for
 guidance if you'd like any, either at the sprints themselves, or here or
 on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.06aeb3e82f4efb77a25ac27608932fab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23338: Warn when unique=True is set on ForeignKey

2014-09-03 Thread Django

#23338: Warn when unique=True is set on ForeignKey
--+
 Reporter:  funkybob  |Owner:  JLinden
 Type:  New feature   |   Status:  assigned
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints.

 If you're tackling this ticket, please don't hesitate to ask me for
 guidance if you'd like any, either at the sprints themselves, or here or
 on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.25d59074c6a59c53656dfc6663dfd457%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

Comment (by shaib):

I think migrate and sqlmigrate are the only required ones for the use-case
(you don't generate or manipulate migrations in a frozen environment).

But I don't like the flag approach -- it essentially passes the problem
from the developer to their user.

I think the correct approach is an app that overrides ("enhances", if you
like) the built-in migration commands, in much the same way that South
enhanced `syncdb`. If it is hard to write as a 3rd-party app, we should
make the changes required to make it easy.

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.7dbf4d7c29473ac2205d68d3602ed349%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21565: values() and values_list() don't work when datetime fields are specified and a GeoManager is used

2014-09-03 Thread Django

#21565: values() and values_list() don't work when datetime fields are specified
and a GeoManager is used
-+-
 Reporter:  brett_energysavvy|Owner:  Marc
 Type:  Bug  |  Tamlyn 
Component:  GIS  |   Status:  closed
 Severity:  Normal   |  Version:  1.5
 Keywords:   |   Resolution:  fixed
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Marc Tamlyn ):

 * owner:   => Marc Tamlyn 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"e9103402c0fa873aea58a6a11dba510cd308cb84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e9103402c0fa873aea58a6a11dba510cd308cb84"
 Fixed #18757, #14462, #21565 -- Reworked database-python type conversions

 Complete rework of translating data values from database

 Deprecation of SubfieldBase, removal of resolve_columns and
 convert_values in favour of a more general converter based approach and
 public API Field.from_db_value(). Now works seamlessly with aggregation,
 .values() and raw queries.

 Thanks to akaariai in particular for extensive advice and inspiration,
 also to shaib, manfre and timograham for their reviews.
 }}}

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.c21274f3a50e486595463014119ac999%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] e91034: Fixed #18757, #14462, #21565 -- Reworked database-...

2014-09-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e9103402c0fa873aea58a6a11dba510cd308cb84
  
https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84
  Author: Marc Tamlyn 
  Date:   2014-09-03 (Wed, 03 Sep 2014)

  Changed paths:
R django/contrib/gis/db/backends/mysql/compiler.py
M django/contrib/gis/db/backends/mysql/operations.py
M django/contrib/gis/db/models/fields.py
M django/contrib/gis/db/models/query.py
M django/contrib/gis/db/models/sql/compiler.py
M django/contrib/gis/db/models/sql/conversion.py
M django/contrib/gis/db/models/sql/query.py
M django/contrib/gis/tests/geoapp/models.py
M django/contrib/gis/tests/geoapp/tests.py
M django/contrib/gis/tests/relatedapp/models.py
M django/contrib/gis/tests/relatedapp/tests.py
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M django/db/backends/mysql/compiler.py
M django/db/backends/mysql/validation.py
M django/db/backends/oracle/base.py
M django/db/backends/oracle/compiler.py
M django/db/backends/sqlite3/base.py
M django/db/models/fields/__init__.py
M django/db/models/fields/subclassing.py
M django/db/models/query.py
M django/db/models/sql/compiler.py
M django/db/models/sql/query.py
M docs/howto/custom-model-fields.txt
M docs/internals/deprecation.txt
M docs/ref/models/fields.txt
M docs/releases/1.8.txt
M tests/aggregation_regress/tests.py
M tests/backends/tests.py
M tests/custom_pk/fields.py
M tests/field_subclassing/models.py
A tests/from_db_value/__init__.py
A tests/from_db_value/models.py
A tests/from_db_value/tests.py
M tests/serializers/models.py

  Log Message:
  ---
  Fixed #18757, #14462, #21565 -- Reworked database-python type conversions

Complete rework of translating data values from database

Deprecation of SubfieldBase, removal of resolve_columns and
convert_values in favour of a more general converter based approach and
public API Field.from_db_value(). Now works seamlessly with aggregation,
.values() and raw queries.

Thanks to akaariai in particular for extensive advice and inspiration,
also to shaib, manfre and timograham for their reviews.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/54076dabdac5f_16673fa8427b12c01104c7%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18757: Examine ways to get rid of DB backend convert_values()

2014-09-03 Thread Django

#18757: Examine ways to get rid of DB backend convert_values()
-+-
 Reporter:  akaariai |Owner:  mjtamlyn
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (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 Marc Tamlyn ):

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


Comment:

 In [changeset:"e9103402c0fa873aea58a6a11dba510cd308cb84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e9103402c0fa873aea58a6a11dba510cd308cb84"
 Fixed #18757, #14462, #21565 -- Reworked database-python type conversions

 Complete rework of translating data values from database

 Deprecation of SubfieldBase, removal of resolve_columns and
 convert_values in favour of a more general converter based approach and
 public API Field.from_db_value(). Now works seamlessly with aggregation,
 .values() and raw queries.

 Thanks to akaariai in particular for extensive advice and inspiration,
 also to shaib, manfre and timograham for their reviews.
 }}}

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.733e27d207ae8d05260ccbab004f5396%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14462: Aggregates default to the database type instead of the field type

2014-09-03 Thread Django

#14462: Aggregates default to the database type instead of the field type
-+-
 Reporter:  WoLpH|Owner:  wogan
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  aggregate,   |  Needs documentation:  0
  annotate, type, coerce |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Marc Tamlyn ):

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


Comment:

 In [changeset:"e9103402c0fa873aea58a6a11dba510cd308cb84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e9103402c0fa873aea58a6a11dba510cd308cb84"
 Fixed #18757, #14462, #21565 -- Reworked database-python type conversions

 Complete rework of translating data values from database

 Deprecation of SubfieldBase, removal of resolve_columns and
 convert_values in favour of a more general converter based approach and
 public API Field.from_db_value(). Now works seamlessly with aggregation,
 .values() and raw queries.

 Thanks to akaariai in particular for extensive advice and inspiration,
 also to shaib, manfre and timograham for their reviews.
 }}}

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5bfa92500ad0c69d760740ab2d067e8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23340: naturaltime documentation doesn't match behavior

2014-09-03 Thread Django

#23340: naturaltime documentation doesn't match behavior
--+
 Reporter:  zachborboa|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.humanize  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit
 * easy:  0 => 1


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints. If you're tackling this ticket, please don't hesitate to ask me
 for guidance if you'd like any, either at the sprints themselves, or here
 or on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.520e4b3a25352b7a0e0be597b8bc7cae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23350: mod_wsgi authentication/authorization docs result in extra memory usage

2014-09-03 Thread Django

#23350: mod_wsgi authentication/authorization docs result in extra memory usage
--+
 Reporter:  GrahamDumpleton   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit
 * easy:  0 => 1


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints. If you're tackling this ticket, please don't hesitate to ask me
 for guidance if you'd like any, either here or on the Django IRC channels,
 where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.a8d0b7ae9dad435b0b86e42dbccd9fb4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19139: OpenLayersWidget's 'Delete all Features' control doesn't respect GeoModelAdmin's modifiable attribute

2014-09-03 Thread Django

#19139: OpenLayersWidget's 'Delete all Features' control doesn't respect
GeoModelAdmin's modifiable attribute
-+-
 Reporter:  fcurella |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  gis admin template   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by claudep):

 * owner:  nobody => claudep
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d6b07dfcc3082fcedf33f0af63535e00%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23376: Inconsistent documentation about required Storage methods

2014-09-03 Thread Django

* keywords: custom storage documentation => custom storage documentation,
afraid-to-commit

Comment:

I've marked this ticket as especially suitable for people following the
'''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
sprints. If you're tackling this ticket, please don't hesitate to ask me
for guidance if you'd like any, either at the sprints themselves, or here
or on the Django IRC channels, where I can be found as ''EvilDMP''.

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.855d718fbb0d6584d0ccd36e47b3e7b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22377: SQL Logging throws an exception when fields have utf-8 characters

2014-09-03 Thread Django

#22377: SQL Logging throws an exception when fields have utf-8 characters
-+-
 Reporter:  rolanvc@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  sql logging for  |  Unreviewed
  utf-8  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 It's not about percent-formatting into bytestrings, as the file imports
 `from __future__ import unicode_literals`. I suspect that content in
 `header_vals` dictionary has some non-ASCII non-Unicode content, which you
 should check and fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.2c4727394232c5b4dbbf2b8f7f9f2a1d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23395: Clarification on PEP 8 E501: line too long (> 79 characters)

2014-09-03 Thread Django

#23395: Clarification on PEP 8 E501: line too long (> 79 characters)
--+
 Reporter:  nrogers64 |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by evildmp):

 * keywords:   => afraid-to-commit


Comment:

 I've marked this ticket as especially suitable for people following the
 '''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
 sprints. If you're tackling this ticket, please don't hesitate to ask me
 for guidance if you'd like any, either here or on the Django IRC channels,
 where I can be found as ''EvilDMP''.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1571e752f965bef7f8601a5d0c8bdfac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 89559b: Fixed #23409 -- Extract PasswordResetForm.get_user...

2014-09-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 89559bcfb096ccc625e0e9ab41e2136fcb32a514
  
https://github.com/django/django/commit/89559bcfb096ccc625e0e9ab41e2136fcb32a514
  Author: Carl Meyer 
  Date:   2014-09-03 (Wed, 03 Sep 2014)

  Changed paths:
M django/contrib/auth/forms.py

  Log Message:
  ---
  Fixed #23409 -- Extract PasswordResetForm.get_users method.

Allows easier customization of policies regarding which users are allowed to
reset their password.

Thanks Aymeric for review.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/54075e6d5925_5513fbb86bad2a0174ef%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23409: PasswordResetForm should not exclude users with unusable passwords

2014-09-03 Thread Django

#23409: PasswordResetForm should not exclude users with unusable passwords
--+--
 Reporter:  carljm|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 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 Carl Meyer ):

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


Comment:

 In [changeset:"89559bcfb096ccc625e0e9ab41e2136fcb32a514"]:
 {{{
 #!CommitTicketReference repository=""
 revision="89559bcfb096ccc625e0e9ab41e2136fcb32a514"
 Fixed #23409 -- Extract PasswordResetForm.get_users method.

 Allows easier customization of policies regarding which users are allowed
 to
 reset their password.

 Thanks Aymeric for review.
 }}}

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e17355bdf0fa147d9cc6af5b3a279d2e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23409: PasswordResetForm should not exclude users with unusable passwords

2014-09-03 Thread Django

#23409: PasswordResetForm should not exclude users with unusable passwords
--+--
 Reporter:  carljm|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.7
 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
--+--

Comment (by aaugustin):

 Looks good. Before committing this change, can you extend the docstring a
 bit to explain why this method was extracted?

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9ea91dca5b43d942c1cef88aa2f43d93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23409: PasswordResetForm should not exclude users with unusable passwords

2014-09-03 Thread Django

#23409: PasswordResetForm should not exclude users with unusable passwords
--+--
 Reporter:  carljm|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.7
 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 carljm):

 * has_patch:  0 => 1


Comment:

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

 No new tests because this is a pure refactoring, not a behavior change.
 Existing tests pass.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.bd956ca2adb76136e8146b8d50c00852%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23409: PasswordResetForm should not exclude users with unusable passwords

2014-09-03 Thread Django

#23409: PasswordResetForm should not exclude users with unusable passwords
+
Reporter: carljm| Owner: nobody
Type: New feature | Status: new
Component: contrib.auth |Version: 1.7
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 `django.contrib.auth.PasswordResetForm` will (silently) not send
a password reset email to any user who has an unusable password set.
Additionally, due to the structure of the code, its not possible to
subclass `PasswordResetForm` to change this behavior without copying the
entire 40-line `save()` method.

This behavior was introduced in #14674, on the theory that a user with an
unusable password probably comes from some external authentication source
(e.g. LDAP), and should not be allowed to reset their password and then
bypass the external authentication source.

That's a reasonable policy for some situations, but there are many other
reasons why one might set an unusable password (e.g. when creating a user
account for someone else), and it's not at all obvious that "unusable
password" should always imply "unable to reset password."

If I could go back in time, I would argue that #14674 should never have
been committed, but since it was (and there have been several Django
releases since), I think the default behavior should probably be left as-
is for backwards-compatibility reasons.

However, I think it should be easy to subclass `PasswordResetForm` and
change this policy. I will submit a pull request that extracts a `def
get_users(self, email):` method of `PasswordResetForm`, whose
responsibility it is, given an email address, to return the matching users
who should receive a password-reset link.

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/049.c9c1e9bc9c6013051f34694f9c03bf05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17101: Add --deploy option to check management command (was: Add "checkdeploy" management command)

2014-09-03 Thread Django

#17101: Add --deploy option to check management command
-+-
 Reporter:  carljm   |Owner:  timgraham
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   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 timgraham):

 * needs_better_patch:  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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2581ee6a08a82313fc4555ddc52eca6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23397: Multipart base64 file decoding of fails with large files when the encoded string contains newlines.

2014-09-03 Thread Django

#23397: Multipart base64 file decoding of fails with large files when the
encoded
string contains newlines.
---+
Reporter: jhobbs |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 jhobbs):

I hit this working on MAAS - http://launchpad.net/maas - which uses Django
for its web interface and API. We recently added an API call for uploading
large files, which is where I ran into this.

MAAS's cli uses python stdlib's Email.generator to build multipart
requests (http://bazaar.launchpad.net/~maas-
maintainers/maas/trunk/view/head:/src/apiclient/multipart.py).

Here's the original bug on launchpad:
https://bugs.launchpad.net/maas/+bug/1363348

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.c08672474d0ed2658f6ca99fabe9da7a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23397: Multipart base64 file decoding of fails with large files when the encoded string contains newlines.

2014-09-03 Thread Django

#23397: Multipart base64 file decoding of fails with large files when the 
encoded
string contains newlines.
---+
 Reporter:  jhobbs |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
---+
Changes (by timgraham):

 * needs_docs:  1 => 0


Comment:

 This looks like more of a bug fix than a "feature" so the release notes
 probably aren't required. Could you give some background how you
 encountered this issue so I can better understand 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.42be7bc522be77bc1fe745715114651b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23408: Automaticly created migration calls callable for default only once

2014-09-03 Thread Django

#23408: Automaticly created migration calls callable for default only once
+
 Reporter:  Harper04|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 Harper04):

 Hi,

 thanks for your time.

 I would argue that this behavior is not intended as best practice to
 create fields like "created_at" fields is to assign a callable.
 Calling it only once during a migration is killing dynamic behavior. What
 if the default value of this field is dependent on another one?

 regards

 Tom

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.20b319204d596c28cbee087cd60c9f98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19139: OpenLayersWidget's 'Delete all Features' control doesn't respect GeoModelAdmin's modifiable attribute

2014-09-03 Thread Django

#19139: OpenLayersWidget's 'Delete all Features' control doesn't respect
GeoModelAdmin's modifiable attribute
-+-
 Reporter:  fcurella |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  gis admin template   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by timgraham):

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


Comment:

 Claude, as someone with more experience with GIS, could you check 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.16570d7c64b8b591af2f4990e7510ade%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 289d38: [1.6.x] Fixed typo in docs/topics/db/transactions....

2014-09-03 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 289d38b731798ed362a5ca343210921e0d5127ab
  
https://github.com/django/django/commit/289d38b731798ed362a5ca343210921e0d5127ab
  Author: Corey Farwell 
  Date:   2014-09-03 (Wed, 03 Sep 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  [1.6.x] Fixed typo in docs/topics/db/transactions.txt.

Backport of 4db75925be from master


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/540738961a47c_7e433feb60e2d2a0827e6%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] de18a6: [1.7.x] Fixed typo in docs/topics/db/transactions....

2014-09-03 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: de18a687ada58c5296f3f41b432aa2d26de8e3d9
  
https://github.com/django/django/commit/de18a687ada58c5296f3f41b432aa2d26de8e3d9
  Author: Corey Farwell 
  Date:   2014-09-03 (Wed, 03 Sep 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  [1.7.x] Fixed typo in docs/topics/db/transactions.txt.

Backport of 4db75925be from master


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/54073894c09ad_d403fe9482712a01037c0%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 4db759: Fixed typo in docs/topics/db/transactions.txt.

2014-09-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4db75925be90affaf49ffe5361b47a56762f93d0
  
https://github.com/django/django/commit/4db75925be90affaf49ffe5361b47a56762f93d0
  Author: Corey Farwell 
  Date:   2014-09-03 (Wed, 03 Sep 2014)

  Changed paths:
M docs/topics/db/transactions.txt

  Log Message:
  ---
  Fixed typo in docs/topics/db/transactions.txt.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/540738857262f_12e43fd286a852bc626cc%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23408: Automaticly created migration calls callable for default only once

2014-09-03 Thread Django

#23408: Automaticly created migration calls callable for default only once
+
 Reporter:  Harper04|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 bmispelon):

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


Comment:

 Hi,

 I can reproduce this indeed. At this point, I'm not sure if this behavior
 is by design or not.

 If not, we should definitely fix this and if it is, we should document it.

 Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.daf63088fbb15b88ae2ba2e022b56db5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23408: Automaticly created migration calls callable for default only once

2014-09-03 Thread Django

#23408: Automaticly created migration calls callable for default only once
+
 Reporter:  Harper04|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Callables on properties for ModelFields are used for various reasons. One
 use case is to autocreate random file names or user passwords if not
 present.
 The migration seems to call them only once because after the migration
 every "Buchung" has the same wlan_password.

 My Model:
 {{{
 def random_wlan_key():
 return
 ''.join(random.SystemRandom().choice("1234567890abcdefghkmnpqrstuvwxyz")
 for i in range(9))

 class Buchung(models.Model):
 [...]
 wlan_passwort = models.CharField(max_length=10,
 default=random_wlan_key)
 }}}

 The generated migration:
 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models, migrations
 import main.models


 class Migration(migrations.Migration):

 dependencies = [
 ('main', '0001_initial'),
 ]

 operations = [
 migrations.AddField(
 model_name='buchung',
 name='wlan_passwort',
 field=models.CharField(default=main.models.random_wlan_key,
 max_length=10),
 preserve_default=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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.daea97137358bd7b43ee8765a8d9103b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by andrewgodwin):

 If it was to work correctly, it would need to be passed to
 `makemigrations`, `migrate`, `sqlmigrate` and `squashmigrations`, but I
 suspect we could get away with just adding it to `migrate` and
 `sqlmigrate`? I'm still not sure about that, but seems better than a
 setting.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.790e31acae7551f85ab8224f57304d16%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by danielmenzel):

 Or perhaps add the list of searched extensions as a class attribute, so
 that monkey-patching is made easier?

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.3fcac7e247ae014fd9ace1917698f962%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by bmispelon):

 Can't we get away with an option passed to the command (something like
 `--pyc`)?

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.037f71b0222ccd3004d2ee2a819864d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by andrewgodwin):

 Well, we'd have to introduce a setting if we wanted to make this work (a
 la SOUTH_INCLUDE_PYC), and I'm somewhat averse to adding more settings
 than necessary. We definitely can't change the default behaviour back;
 people were seeing all sorts of bugs when switching branches due to .pyc
 files.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.121e8791441bfdea75f5e198b7e22636%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23405: Blank-able CharFields require default=''

2014-09-03 Thread Django

Comment (by yuvadm):

Replying to [comment:3 charettes]:
> I might not want the existing rows of the altered table to be equals to
`''` but a totally different value (e.g. `'active'`) even if it's not an
explicit `default` value used by the application.
>
> I think Django should continue to prompt the user instead of guessing
like South did.

This happens even for new fields being added. I would argue that any
existing field change is a data migration anyway, and requires manual
intervention.

In any case, my complaint pertains to new fields being introduced, and in
which case `default=''` is alread assumed by Django in any other aspect.
So why not in this aspect as well?

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.65d7f5231b3e7823f729a381a840%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23405: Blank-able CharFields require default=''

2014-09-03 Thread Django

* cc: charettes (added)

Comment:

Replying to [comment:2 yuvadm]:
> Of course I can add `''` as the default value. It just kind of goes
against the usual convention that CharField should never be null and
always use `''` as a default for null/blank values. It also goes against
what South would do, that's the core of my confusion.

I'd advocate the new behavior makes more sense. If I add a `status =
models.CharField(max_length=20, blank=True)` field I might not want the
existing rows of the altered table to be equals to `''` but a totally
different value (e.g. `'active'`) even if it's not an explicit `default`
value used by the application.

I think Django should continue to prompt the user instead of guessing like
South did.

--
Ticket URL:
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.9f7894f56cbe96a9b7fdc8a21d211b45%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23407: makemigrations doesn't use --noinput

2014-09-03 Thread Django

#23407: makemigrations doesn't use --noinput
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  Migrations   |   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
-+-

Comment (by bmispelon):

 I'll also note that the current documentation for `makemigrations` [1] is
 incorrect since it states:

 > The --noinput option may be provided to suppress all user prompts.

 Which is incorrect.

 [1] https://docs.djangoproject.com/en/1.7/ref/django-admin/#django-admin-
 makemigrations

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2887a00b9ab0a21d93ec37a502ec6850%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 The reason for the change was because treating an orphan `.pyc` as a real
 migration causes too many problems with things like switching branches in
 git.

 I think not looking for `.pyc` files is the right default behavior, but I
 wouldn't have any problem with some form of configurability to support
 things like cx_Freeze.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.bd84121334228860d55938ef68968f16%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  danielmenzel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * cc: andrewgodwin (added)
 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I forget the reasoning, but I believe the decision was not to support
 frozen environments. We should at least document 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.f040ee59b721c0650763a151358deddc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23407: makemigrations doesn't use --noinput

2014-09-03 Thread Django

#23407: makemigrations doesn't use --noinput
+
   Reporter:  bmispelon |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  1.7
   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 |
+
 #22862 added the `--noinput` to the `makemigrations` command but only when
 using `--merge`.

 It seems to me that it would be a useful addition to the plain
 `makemigrations` too and could work like this:

 * If the migrations can be created without user input, create it
 * If not, raise an error.

 I tried changing the code to use `MigrationQuestioner` instead of
 `InteractiveMigrationQuestioner` but it seems that this just creates a
 migration with `default=None` which might not be what you want.

 Implementing a new questioner object like this seems to work in my limited
 testcase:
 {{{#!python
 class NonInteractiveQuestioner(MigrationQuestioner):
 def ask_not_null_addition(self, field_name, model_name):
 raise NotImplementedError

 def ask_rename(self, model_name, old_name, new_name, field_instance):
 raise NotImplementedError

 def ask_rename_model(self, old_model_state, new_model_state):
 raise NotImplementedError

 def ask_merge(self, app_label):
 raise NotImplementedError
 }}}

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.7a3c50c25d4cb9ea56df46dd8466bac7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

2014-09-03 Thread Django

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:   |  Owner:  nobody
  danielmenzel   | Status:  new
 Type:  Bug  |Version:  1.7
Component:   |   Keywords:  migrations, .pyc, frozen, cx_Freeze
  Migrations |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 == Description ==

 When only '''.pyc''' files are available, for example in a frozen
 environment after running ''cx_Freeze'' or similar tools, migrations no
 longer work: the migrate command does not find any migrations to apply,
 and produces the following output:

 {{{
 Operations to perform:
   Synchronize unmigrated apps: 
   Apply all migrations: (none)
 Synchronizing apps without migrations:
   Creating tables...
 Creating table 
   Installing custom SQL...
   Installing indexes...
 Running migrations:
   No migrations to apply.
   Your models have changes that are not yet reflected in a migration, and
 so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 }}}

 Subsequent operations then fail because the database is unmigrated.

 The typical content of a frozen migrations folder looks like this:

 {{{
 django
   contrib
 contenttypes
   migrations
 __init__.pyc
 0001_initial.pyc
 }}}


 == Analysis ==

 Due to issue [https://code.djangoproject.com/ticket/23237], there was a
 change in django.db.migrations.loader
 
([https://code.djangoproject.com/changeset/267630ad50c69ebfe594de37a0636264aa5be7d6]):
 Previously, migrations were found if they had a '''.py''', '''.pyc''', or
 '''.pyo''' extension. Now only migrations with '''.py''' extensions are
 found.

 Perhaps it would be possible to add a check if Django is running in a
 frozen environment:

 {{{
 if hasattr(sys, 'frozen'):
 extensions = ('.py', '.pyc')
 else:
 extensions = ('.py', )
 ...
 if name.endswith(extensions):
 ...
 }}}

 or make the list of allowed extensions configurable by the user.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.7cd655e2c3bf63b7339739759b89274c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23270: select_related on fields pointing to subclasses does not work when using defer

2014-09-03 Thread Django

#23270: select_related on fields pointing to subclasses does not work when using
defer
-+-
 Reporter:  islavov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7-rc-2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related   |  Needs documentation:  0
  defer  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by timgraham):

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


Comment:

 See PR for comments.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.42d4ff06c7430aa5b517f76d40952bae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23405: Blank-able CharFields require default=''

2014-09-03 Thread Django

#23405: Blank-able CharFields require default=''
+--
 Reporter:  yuvadm  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 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 yuvadm):

 Of course I can add `''` as the default value. It just kind of goes
 against the usual convention that CharField should never be null and
 always use `''` as a default for null/blank values. It also goes against
 what South would do, that's the core of my confusion.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.632fbaa0d0a0fbdcf135395c2561a17f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23405: Blank-able CharFields require default=''

2014-09-03 Thread Django

#23405: Blank-able CharFields require default=''
+--
 Reporter:  yuvadm  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 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 bmispelon):

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


Comment:

 Hi,

 In this case, the migrations framework provides you with two choices:

 {{{
 $ python manage.py makemigrations
 You are trying to add a non-nullable field 'bar' to foo without a default;
 we can't do that (the database needs something to populate existing rows).
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows)
  2) Quit, and let me add a default in models.py
 Select an option:

 }}}

 It seems to me like a better approach than guessing `default=''` (explicit
 being better than implicit and all).

 Is that not sufficient for your use-case?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.18e6e31962861a3f2c899d547a446e61%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22377: SQL Logging throws an exception when fields have utf-8 characters

2014-09-03 Thread Django

#22377: SQL Logging throws an exception when fields have utf-8 characters
-+-
 Reporter:  rolanvc@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  sql logging for  |  Unreviewed
  utf-8  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kahnert):

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


Comment:

 Here is a traceback:
 {{{
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 399, in
 execute_from_command_line
 utility.execute()
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 392, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 242, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 285, in execute
 output = self.handle(*args, **options)
   File
 
"/home/kahnert/pycharm/schedules/schedules/data/management/commands/import_data.py",
 line 35, in handle
 self.parse_file(fname)
   File
 
"/home/kahnert/pycharm/schedules/schedules/data/management/commands/import_data.py",
 line 40, in parse_file
 self.parse_entry(cols)
   File
 
"/home/kahnert/pycharm/schedules/schedules/data/management/commands/import_data.py",
 line 61, in parse_entry
 row_header, created = OIRowHeader.objects.get_or_create(**header_vals)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/manager.py", line 154, in get_or_create
 return self.get_queryset().get_or_create(**kwargs)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 376, in get_or_create
 return self.get(**lookup), False
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 304, in get
 num = len(clone)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 77, in __len__
 self._fetch_all()
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 857, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 220, in iterator
 for row in compiler.results_iter():
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 713, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 786, in execute_sql
 cursor.execute(sql, params)
   File "/mnt/schedenv/local/lib/python2.7/site-
 packages/django/db/backends/util.py", line 78, in execute
 logger.debug('(%.3f) %s; args=%s' % (duration, sql, params),
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 450:
 ordinal not in range(128)
 }}}
 I can't provide the data values, most likely some russian or chinese
 string, but I think the bug is obvious if you look into
 `django.db.backends.util.CursorDebugWrapper`:
 - Python 2
 - percent-formatting into bytestrings (`str`-Type)
 -> UnicodeDecodeError for any non-ascii char

 The solution should be as simple as: Use `six` string types

 This is realy a hassle, since you have to work around '''de'''bugging Code
 at the moment.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.69b396fd87bf0f131a4474609d45ad8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23405: Blank-able CharFields require default=''

2014-09-03 Thread Django

#23405: Blank-able CharFields require default=''
+
 Reporter:  yuvadm  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 There's a weird behavior in Django 1.7 migrations as opposed to 1.6 +
 South.

 Consider a simple blank-able CharField:

 {{{
 comment = models.CharField(max_length=20, blank=True)
 }}}

 In Django 1.6 + South, adding a migration to add this field would auto-
 generate `default=''` in the migration. In Django 1.7 the migration now
 throws: "You are trying to add a non-nullable field 'test' to question
 without a default".

 My understanding is that this is the proper convention for blank-able
 fields, and in that case the migrations need to support it properly.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.efae9b8b3cd21780aebdd8e8092b2866%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23399: Update int_to_base36

2014-09-03 Thread Django

#23399: Update int_to_base36
-+-
 Reporter:  liminspace   |Owner:
 Type:   |  liminspace
  Cleanup/optimization   |   Status:  new
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This implementation isn't backwards compatible with respect to the errors
 it raises on invalid inputs.

 Some benchmarks would be helpful as far as speed goes.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a3923735ffb6a26c0bc4b2f0458ccbd1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23404: Django modelformset returns the same data inserted in the previous insert when opening the same page for inserting new data

2014-09-03 Thread Django

#23404: Django modelformset returns the same data inserted in the previous 
insert
when opening the same page for inserting new data
-+-
 Reporter:  guruprasad   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  modelformset_factory   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I think you need to look it `inlineformset_factory` and/or
 `BaseInlineFormSet`. As far as I can tell, `BaseModelFormSet` is working
 [https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#changing-
 the-queryset as documented].

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.88cc2588440fe80cbe4ae3cfdc812fce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23404: Django modelformset returns the same data inserted in the previous insert when opening the same page for inserting new data

2014-09-03 Thread Django

Comment (by guruprasad):

Replying to [comment:2 timgraham]:
> Any chance the browser is auto-populating the data from the last form
fill? If not, this would be a pretty obvious bug so the problem is likely
in your code although I don't see anything odd.

Tim, I used pdb to render the html on the server side and it is having the
data of all the fields in the model populated in the formset when it has
to be rendered empty for a GET request. I tried it on a totally different
codebase and app and I could see the same issue.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.5604587dee307a04ae286456fcbf0534%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23404: Django modelformset returns the same data inserted in the previous insert when opening the same page for inserting new data

2014-09-03 Thread Django

#23404: Django modelformset returns the same data inserted in the previous 
insert
when opening the same page for inserting new data
-+-
 Reporter:  guruprasad   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  modelformset_factory   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Any chance the browser is auto-populating the data from the last form
 fill? If not, this would be a pretty obvious bug so the problem is likely
 in your code although I don't see anything odd.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.08d55aca6d4a8e9f7bbd2e157bbb2ad6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23403: Sitemap bug

2014-09-03 Thread Django

#23403: Sitemap bug
---+--
 Reporter:  igorcc |Owner:  igorcc
 Type:  Bug|   Status:  assigned
Component:  contrib.sitemaps   |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  date utctimetuple  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * needs_tests:  0 => 1
 * easy:  1 => 0


Old description:

> When building a sitemap I receive
> jango Version:  1.7
> Exception Type: AttributeError
> Exception Value:'datetime.date' object has no attribute
> 'utctimetuple'
>
> Exception Location: /Django/lib/python2.7/site-
> packages/django/contrib/sitemaps/views.py in sitemap, line 78
>
> Workaround can be done as:
> diff --git a/django/contrib/sitemaps/views.py
> b/django/contrib/sitemaps/views.py
> index aa184e9..d74c55b 100644
> --- a/django/contrib/sitemaps/views.py
> +++ b/django/contrib/sitemaps/views.py
> @@ -8,6 +8,7 @@ from django.http import Http404
>  from django.template.response import TemplateResponse
>  from django.utils import six
>  from django.utils.http import http_date
> +from datetime import datetime
>

>  def x_robots_tag(func):
> @@ -71,7 +72,7 @@ def sitemap(request, sitemaps, section=None,
>  raise Http404("No page '%s'" % page)
>  response = TemplateResponse(request, template_name, {'urlset':
> urls},
>  content_type=content_type)
> -if hasattr(site, 'latest_lastmod'):
> +if hasattr(site, 'latest_lastmod') and type(site.latest_lastmod) is
> datetime:
>  # if latest_lastmod is defined for site, set header so as
>  # ConditionalGetMiddleware is able to send 304 NOT MODIFIED
>  response['Last-Modified'] = http_date(

New description:

 When building a sitemap I receive
 {{{
 Django Version: 1.7
 Exception Type: AttributeError
 Exception Value:'datetime.date' object has no attribute
 'utctimetuple'

 Exception Location: /Django/lib/python2.7/site-
 packages/django/contrib/sitemaps/views.py in sitemap, line 78

 }}}
 Workaround can be done as:
 {{{
 diff --git a/django/contrib/sitemaps/views.py
 b/django/contrib/sitemaps/views.py
 index aa184e9..d74c55b 100644
 --- a/django/contrib/sitemaps/views.py
 +++ b/django/contrib/sitemaps/views.py
 @@ -8,6 +8,7 @@ from django.http import Http404
  from django.template.response import TemplateResponse
  from django.utils import six
  from django.utils.http import http_date
 +from datetime import datetime


  def x_robots_tag(func):
 @@ -71,7 +72,7 @@ def sitemap(request, sitemaps, section=None,
  raise Http404("No page '%s'" % page)
  response = TemplateResponse(request, template_name, {'urlset': urls},
  content_type=content_type)
 -if hasattr(site, 'latest_lastmod'):
 +if hasattr(site, 'latest_lastmod') and type(site.latest_lastmod) is
 datetime:
  # if latest_lastmod is defined for site, set header so as
  # ConditionalGetMiddleware is able to send 304 NOT MODIFIED
  response['Last-Modified'] = http_date(
 }}}

--

Comment:

 Could you please include code to reproduce the issue (ideally as a test
 for Django's test suite)? Did your code work in Django 1.6?

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.49beec6b422f73388cfc7d7582d9edf5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21001: Non working SQL generated for Oracle when doing .exclude('')

2014-09-03 Thread Django

#21001: Non working SQL generated for Oracle when doing .exclude('')
-+-
 Reporter:  greenRocker  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 Per our [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy], 1.4 is only receiving
 security fixes so this issue won't be fixed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.c0e22700da3252c60a48646a293ab6b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23404: Django modelformset returns the same data inserted in the previous insert when opening the same page for inserting new data

2014-09-03 Thread Django

#23404: Django modelformset returns the same data inserted in the previous 
insert
when opening the same page for inserting new data
-+-
 Reporter:  guruprasad   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  modelformset_factory   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by guruprasad):

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


Old description:

> {{{
> # models.py
> import datetime
>
> from django.db import models
>

> class Category(models.Model):
> category_name = models.CharField(unique=True, max_length=100)
> is_enabled = models.BooleanField(default=True)
> created_date = models.DateField(default=datetime.date.today)
>
> def __unicode__(self):
> return self.category_name
>
> class Website(models.Model):
> url = models.URLField(unique=True)
> site_name = models.CharField(max_length=100)
> vertical_category = models.ForeignKey(Category,
> related_name="websites")
> unique_users_per_day = models.IntegerField()
> page_views_per_day = models.IntegerField()
> unique_users_per_month = models.IntegerField()
> page_views_per_month = models.IntegerField()
>
> class Section(models.Model):
> website = models.ForeignKey(Website, related_name="sections")
> url = models.URLField(unique=True)
> section_name = models.CharField(max_length=100)
>
> }}}
>

> {{{
> # forms.py
> from django import forms
> from django.forms.models import modelformset_factory, BaseModelFormSet
> from .models import Website, Section
>

> class AddWebsiteForm(forms.ModelForm):
> def __init__(self, *args, **kwargs):
> super(AddWebsiteForm, self).__init__(*args, **kwargs)
> self.fields['unique_users_per_day'].widget = forms.TextInput()
> self.fields['page_views_per_day'].widget = forms.TextInput()
> self.fields['unique_users_per_month'].widget = forms.TextInput()
> self.fields['page_views_per_month'].widget = forms.TextInput()
> self.fields['vertical_category'].empty_label = "Vertical
> Category"
>
> class Meta:
> model = Website
> exclude = []
>

> class AddSectionForm(forms.ModelForm):
> class Meta:
> model = Section
> exclude = ['website',]
>

> class FirstRequiredFormSet(BaseModelFormSet):
> def __init__(self, *args, **kwargs):
> super(FirstRequiredFormSet, self).__init__(*args, **kwargs)
> for form in self.forms:
> form.empty_permitted = False
>
> AddSectionFormSet = modelformset_factory(Section, AddSectionForm,
> formset=FirstRequiredFormSet)
>
> }}}
>

> {{{
>
> from django.shortcuts import render, redirect
> from django.core.urlresolvers import reverse_lazy
> from django.forms.formsets import INITIAL_FORM_COUNT
>
> from .forms import AddWebsiteForm, AddSectionFormSet
>
> def add_website(request):
> import pdb; pdb.set_trace()
> if request.method == "POST":
>
> website_form = AddWebsiteForm(request.POST)
> section_formset = AddSectionFormSet(request.POST)
>
> if website_form.is_valid() and section_formset.is_valid():
> website = website_form.save()
> sections = section_formset.save(commit=False)
>
> for section in sections:
> section.website = website
> section.save()
>
> if 'add_another' in request.POST:
> return redirect(reverse_lazy('login'))
> else:
> return redirect(reverse_lazy('login'))
> else:
> website_form = AddWebsiteForm()
> section_formset = AddSectionFormSet()
>
> return render(request,
>   "website/add.html",
>   {
>   "website_form" : website_form,
>   "section_formset": section_formset
>   })
>
> }}}
>
> {{{
> 
> 
> {{ website_form }}
> 
> 
> {{ section_formset }}
> 
> 
>
> }}}
>
> After submitting the form for the first time and inserting some data, I
> visit the same URL for inserting more data. But the form of section
> formset is pre-populated with the data inserted the previous time.

New description:

 {{{
 # models.py
 import datetime

 from django.db import models


 class Category(models.Model):
 category_name = models.CharField(unique=True, max_length=100)
 is_enabled = models.BooleanField(default=True)
 creat

[Django] #23404: Django modelformset returns the same data inserted in the previous insert when opening the same page for inserting new data

2014-09-03 Thread Django

#23404: Django modelformset returns the same data inserted in the previous 
insert
when opening the same page for inserting new data
+--
 Reporter:  guruprasad  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.6
 Severity:  Normal  |   Keywords:  modelformset_factory
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 {{{
 # models.py
 import datetime

 from django.db import models


 class Category(models.Model):
 category_name = models.CharField(unique=True, max_length=100)
 is_enabled = models.BooleanField(default=True)
 created_date = models.DateField(default=datetime.date.today)

 def __unicode__(self):
 return self.category_name

 class Website(models.Model):
 url = models.URLField(unique=True)
 site_name = models.CharField(max_length=100)
 vertical_category = models.ForeignKey(Category,
 related_name="websites")
 unique_users_per_day = models.IntegerField()
 page_views_per_day = models.IntegerField()
 unique_users_per_month = models.IntegerField()
 page_views_per_month = models.IntegerField()

 class Section(models.Model):
 website = models.ForeignKey(Website, related_name="sections")
 url = models.URLField(unique=True)
 section_name = models.CharField(max_length=100)

 }}}


 {{{
 # forms.py
 from django import forms
 from django.forms.models import modelformset_factory, BaseModelFormSet
 from .models import Website, Section


 class AddWebsiteForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(AddWebsiteForm, self).__init__(*args, **kwargs)
 self.fields['unique_users_per_day'].widget = forms.TextInput()
 self.fields['page_views_per_day'].widget = forms.TextInput()
 self.fields['unique_users_per_month'].widget = forms.TextInput()
 self.fields['page_views_per_month'].widget = forms.TextInput()
 self.fields['vertical_category'].empty_label = "Vertical Category"

 class Meta:
 model = Website
 exclude = []


 class AddSectionForm(forms.ModelForm):
 class Meta:
 model = Section
 exclude = ['website',]


 class FirstRequiredFormSet(BaseModelFormSet):
 def __init__(self, *args, **kwargs):
 super(FirstRequiredFormSet, self).__init__(*args, **kwargs)
 for form in self.forms:
 form.empty_permitted = False

 AddSectionFormSet = modelformset_factory(Section, AddSectionForm,
 formset=FirstRequiredFormSet)

 }}}


 {{{

 from django.shortcuts import render, redirect
 from django.core.urlresolvers import reverse_lazy
 from django.forms.formsets import INITIAL_FORM_COUNT

 from .forms import AddWebsiteForm, AddSectionFormSet

 def add_website(request):
 import pdb; pdb.set_trace()
 if request.method == "POST":

 website_form = AddWebsiteForm(request.POST)
 section_formset = AddSectionFormSet(request.POST)

 if website_form.is_valid() and section_formset.is_valid():
 website = website_form.save()
 sections = section_formset.save(commit=False)

 for section in sections:
 section.website = website
 section.save()

 if 'add_another' in request.POST:
 return redirect(reverse_lazy('login'))
 else:
 return redirect(reverse_lazy('login'))
 else:
 website_form = AddWebsiteForm()
 section_formset = AddSectionFormSet()

 return render(request,
   "website/add.html",
   {
   "website_form" : website_form,
   "section_formset": section_formset
   })

 }}}

 {{{
 
 
 {{ website_form }}
 
 
 {{ section_formset }}
 
 

 }}}

 After submitting the form for the first time and inserting some data, I
 visit the same URL for inserting more data. But the form of section
 formset is pre-populated with the data inserted the previous time.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.d096b3000e411f084c687231d432aabd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23396: Regression in #14334 causes ValueError to be thrown on ValuesQuerySets

2014-09-03 Thread Django

#23396: Regression in #14334 causes ValueError to be thrown on ValuesQuerySets
-+-
 Reporter:  gabejackson  |Owner:
 Type:  Bug  |  gabejackson
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  master
 Severity:  Release blocker  |   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
-+-

Comment (by gabejackson):

 Final PR is here: https://github.com/django/django/pull/3154

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ad688124f5b60a55a7396ec237a366a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23359: Add ability to show the migration plan

2014-09-03 Thread Django

#23359: Add ability to show the migration plan
-+---
 Reporter:  Markush2010  |Owner:  Markush2010
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by Markush2010):

 * needs_docs:  0 => 1


Comment:

 I added another PR (https://github.com/django/django/pull/3153) that adds
 a dedicated `showmigrations` command which then also takes care of
 `--list` from the `migrate` command.

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.b640785c6e900be8a68f2fd1acc19791%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23403: Sitemap bug

2014-09-03 Thread Django

#23403: Sitemap bug
---+--
 Reporter:  igorcc |Owner:  igorcc
 Type:  Bug|   Status:  assigned
Component:  contrib.sitemaps   |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  date utctimetuple  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by igorcc):

 * owner:  nobody => igorcc
 * needs_better_patch:   => 0
 * status:  new => assigned
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.164c73a4a0dd77956b3e76034cf815f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23403: Sitemap bug

2014-09-03 Thread Django

#23403: Sitemap bug
--+---
 Reporter:  igorcc|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.sitemaps  |Version:  1.7
 Severity:  Normal|   Keywords:  date utctimetuple
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+---
 When building a sitemap I receive
 jango Version:  1.7
 Exception Type: AttributeError
 Exception Value:'datetime.date' object has no attribute
 'utctimetuple'

 Exception Location: /Django/lib/python2.7/site-
 packages/django/contrib/sitemaps/views.py in sitemap, line 78

 Workaround can be done as:
 diff --git a/django/contrib/sitemaps/views.py
 b/django/contrib/sitemaps/views.py
 index aa184e9..d74c55b 100644
 --- a/django/contrib/sitemaps/views.py
 +++ b/django/contrib/sitemaps/views.py
 @@ -8,6 +8,7 @@ from django.http import Http404
  from django.template.response import TemplateResponse
  from django.utils import six
  from django.utils.http import http_date
 +from datetime import datetime


  def x_robots_tag(func):
 @@ -71,7 +72,7 @@ def sitemap(request, sitemaps, section=None,
  raise Http404("No page '%s'" % page)
  response = TemplateResponse(request, template_name, {'urlset': urls},
  content_type=content_type)
 -if hasattr(site, 'latest_lastmod'):
 +if hasattr(site, 'latest_lastmod') and type(site.latest_lastmod) is
 datetime:
  # if latest_lastmod is defined for site, set header so as
  # ConditionalGetMiddleware is able to send 304 NOT MODIFIED
  response['Last-Modified'] = http_date(

--
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.019597e8f7900dc642799aad1d581d6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23402: Minor incorrect links.

2014-09-03 Thread Django

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

Comment:

Hi,

I'm not sure I understand the issue you're reporting and I can't reproduce
any error.

The documentation switcher widget is not very smart: for every page of the
documentation, it checks if that page is available in another version and
if that's the case, a link to the same page for that version of Django is
included.

The release notes are just a page like any others, there's no special
casing for them.

Closing this as "worksforme". Please reopen if I've misunderstood your
issue.

Thanks

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.ed97096d861f75dc6ceda5a0f759401b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

76 matches

Mail list logo