Re: [Django] #19161: Line missing on Dev documentation

[Django]

#19161: Line missing on Dev documentation
-+
 Reporter:  DavidW   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by russellm):

 * severity:  Normal => Release blocker


Comment:

 Actually, this should be a release blocker, since it's a fundamentally
 misleading piece of documentation in a new feature.

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

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

Re: [Django] #19161: Line missing on Dev documentation

[Django]

#19161: Line missing on Dev documentation
---+
 Reporter:  DavidW |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by russellm):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19179: NamedUrlSessionWizard and NamedUrlCookieWizard undocumented (was: No mention of Multiiple Inheritance required for NamedUrlWizardView)

[Django]

#19179: NamedUrlSessionWizard and NamedUrlCookieWizard undocumented
-+-
 Reporter:  tom@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  SessionWizardView,   | Triage Stage:  Accepted
  NamedUrlWizardView |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by timo):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19208: Daemon mode and mod_wsgi configuration.

[Django]

#19208: Daemon mode and mod_wsgi configuration.
---+
 Reporter:  grahamd|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19101: Non ascii chars in form cause Internal Server Error

[Django]

#19101: Non ascii chars in form cause Internal Server Error
-+-
 Reporter:  kristall |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  encoding | 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 claudep):

 Now that we know for sure that the content of the request is `x-www-form-
 urlencoded`, it should be encoded and composed of only ASCII chars at this
 point, AFAIK, so decoding it with 'utf-8' or 'ascii' or even any encoding
 should not make any difference. The charset specified in the request is
 then used later in `QueryDict` initialization to decode (in the sense of
 url decoding) the query string content.

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

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

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * owner:  mtredinnick => akaariai


Comment:

 I have update the work, it can be found from:
 https://github.com/akaariai/django/compare/ticket_18748...ticket_18748_comb

 Note that the work is now based on patch found from #18748 - the reason is
 that I am very likely going to commit that patch soon, and because that
 patch and this one conflict I didn't want to resolve conflicts again after
 commit of #18748.

 There is at least on thing I have to do: refactor the added patch for this
 ticket. It has way too much stuff in one test method. Otherwise I don't
 know of any issues in the patch and djangobench doesn't complain about
 performance.

 So, I will likely try to get this patch into Django soon enough.

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

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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  regression   | 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 Claude Paroz ):

 In [changeset:"b4627bcabe6704c5bd1cbfb2d3a1421e05c29cd7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4627bcabe6704c5bd1cbfb2d3a1421e05c29cd7"
 [1.5.x] Fixed #18575 -- Empty DATABASES should default to dummy backend

 Thanks delormema...@gmail.com for the report.

 Backport of f1cc2be0c from master.
 }}}

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

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

[django/django] b4627b: [1.5.x] Fixed #18575 -- Empty DATABASES should def...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: b4627bcabe6704c5bd1cbfb2d3a1421e05c29cd7
  
https://github.com/django/django/commit/b4627bcabe6704c5bd1cbfb2d3a1421e05c29cd7
  Author: Claude Paroz 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py
M django/db/__init__.py
M django/db/utils.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #18575 -- Empty DATABASES should default to dummy backend

Thanks delormema...@gmail.com for the report.

Backport of f1cc2be0c from master.



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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  regression   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"f1cc2be0c53858b673afc3b26347d3bb25e424f6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1cc2be0c53858b673afc3b26347d3bb25e424f6"
 Fixed #18575 -- Empty DATABASES should default to dummy backend

 Thanks delormema...@gmail.com 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f1cc2b: Fixed #18575 -- Empty DATABASES should default to ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f1cc2be0c53858b673afc3b26347d3bb25e424f6
  
https://github.com/django/django/commit/f1cc2be0c53858b673afc3b26347d3bb25e424f6
  Author: Claude Paroz 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py
M django/db/__init__.py
M django/db/utils.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  Fixed #18575 -- Empty DATABASES should default to dummy backend

Thanks delormema...@gmail.com for the report.



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

[Django] #19208: Daemon mode and mod_wsgi configuration.

[Django]

#19208: Daemon mode and mod_wsgi configuration.
---+
 Reporter:  grahamd|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The mod_wsgi documentation at:

 https://docs.djangoproject.com/en/1.4/howto/deployment/wsgi/modwsgi/

 says:

 """
 "Daemon mode" is the recommended mode for running mod_wsgi (on non-Windows
 platforms). See the official mod_wsgi documentation for details on setting
 up daemon mode. The only change required to the above configuration if you
 use daemon mode is that you can't use WSGIPythonPath; instead you should
 use the python-path option to WSGIDaemonProcess, for example:

 WSGIDaemonProcess example.com python-
 path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
 """

 This information fails to mention that you also need to set
 WSGIProcessGroup to delegate the Django instance to run in the daemon
 process group. Worse is that it says 'The only change required to the
 above configuration if you use daemon mode'. Thus those who never actually
 read documentation properly and will just cut and paste will have issues.

 Results is that keep seeing examples of people who have not done this and
 who have either done one of the following:

 1. Set WSGIPythonPath and python-path and then are oblivious to the fact
 that they aren't running in daemon mode and are still running in embedded
 mode.
 2. Don't set WSGIPythonPath and then get that Django settings module can't
 be found on startup because it doesn't know where to find it.

 I noted this common problem of WSGIProcessGroup not being set in:

 http://blog.dscpl.com.au/2012/10/why-are-you-using-embedded-mode-of.html

 I didn't realise until now that Django documentation on mod_wsgi was
 contributing to that.

 Suggest that:

 """
 "Daemon mode" is the recommended mode for running mod_wsgi (on non-Windows
 platforms). See the official mod_wsgi documentation for details on setting
 up daemon mode. The only change required to the above configuration if you
 use daemon mode is that you can't use WSGIPythonPath; instead you should
 use the python-path option to WSGIDaemonProcess, for example:

 WSGIDaemonProcess example.com python-
 path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
 """

 be changed to something like:

 """
 "Daemon mode" is the recommended mode for running mod_wsgi (on non-Windows
 platforms). To create the required daemon process group and delegate the
 Django instance to run in it you will need to add appropriate
 WSGIDaemonProcess and WSGIProcessGroup directives. A further change
 required to the above configuration if you use daemon mode is that you
 can't use WSGIPythonPath; instead you should use the python-path option to
 WSGIDaemonProcess, for example:

 WSGIDaemonProcess example.com python-
 path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
 WSGIProcessGroup example.com

 See the official mod_wsgi documentation for details on setting up daemon
 mode.
 """

 The link into the mod_wsgi documentation is probably best set to:

 
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process

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

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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | 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 aaugustin):

 To sum up, the patch for this ticket should:
 - activate the dummy backend when `settings.DATABASES` is empty,
 - change the default value in `global_settings.py` to match the
 documentation, and add a comment explaining that the dummy backend will be
 used if the setting is left empty,

 18575-3.diff is nearly RFC — it's only missing the comment.

 I checked with Carl on IRC that this is an improvement over #16873. At the
 time, no one had thought that people would write `DATABASES = {}` in their
 settings files, so this use case wasn't supported.

 Making the test runner aware of the dummy backend — so it doesn't attempt
 to create the database before the tests and drop it after — was forked to
 #19192.

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

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

[django/django] 95f3f0: [1.5.x] Fixed a typo in aff9b2f.

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 95f3f0cbbe65cf6eead85f544fc0826e5e6a2ef4
  
https://github.com/django/django/commit/95f3f0cbbe65cf6eead85f544fc0826e5e6a2ef4
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/humanize/tests.py

  Log Message:
  ---
  [1.5.x] Fixed a typo in aff9b2f.

Thanks void.

Backport of effe96b from master.



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

[django/django] effe96: Fixed a typo in aff9b2f.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: effe96b303aba45a88e1a24f613fef9ad974a53a
  
https://github.com/django/django/commit/effe96b303aba45a88e1a24f613fef9ad974a53a
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/humanize/tests.py

  Log Message:
  ---
  Fixed a typo in aff9b2f.

Thanks void.



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

Re: [Django] #19101: Non ascii chars in form cause Internal Server Error

[Django]

#19101: Non ascii chars in form cause Internal Server Error
-+-
 Reporter:  kristall |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  encoding | 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 aaugustin):

 I'd prefer to fork the part that fixes #5076 to that ticket. I left a
 comment over there.

 The `force_str` when instantiating the `QueryDict` looks suspect to me — I
 suppose `self.body` contains bytes at this point, wouldn't it make sense
 to decode them with the charset of the request rather than with utf-8?

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

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

Re: [Django] #5076: Request object should try to determine encoding

[Django]

#5076: Request object should try to determine encoding
-+-
 Reporter:  dbr    |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  unicode conversion   |  Needs documentation:  0
  charset POST request   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 The patch for #19101 includes the fix for this ticket. However, I'd prefer
 to fix these issues separately, so I'm going to comment here.

 I'd like to see a more robust
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 media type]
 parsing. The grammar is simple enough to implement correctly. For example:

 {{{
 content_type = self.META.get('CONTENT_TYPE', '')
 content_type, _, parameters = content_type.partition(';')
 content_params = {}
 for parameter in parameters.split(';'):
 k, _, v = parameter.strip().partition('=')
 content_params[k] = v
 }}}

 It could make sense to move this to a utility function or at least as a
 method of the HttpRequest object, as in the patches above.

 Then we just do:
 {{{
 if 'charset' in content_params:
 ...
 }}}

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

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

[django/django] 0b98ef: Ensure that version detection in docs from 373df56...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0b98ef632147a26f2430a3ede48d9e58983cc3ae
  
https://github.com/django/django/commit/0b98ef632147a26f2430a3ede48d9e58983cc3ae
  Author: Ramiro Morales 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M docs/conf.py

  Log Message:
  ---
  Ensure that version detection in docs from 373df56d uses the right Django 
copy.



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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | 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 ptone):

 In handsight - I would have closed this as a dupe of #18053 instead of the
 other way - that ticket preceded this and represents the general case,
 while this is a specific case.

 A question we should ask is how can we leave the best trail for others to
 understand what is happening - at a minimum, I think we should add a
 comment to global_settings explaining that initialization will set the
 connection to use the dummy backend if not set in settings.py

 At that point I'm not sure whether having global settings be {} or leave
 it set to dummy backend as is currently the case matters - the comment
 will hopefully clarify for anyone who sets no DB or sets it to {} and
 wonders how the dummy backend got involved.

 Perhaps adding a TODO comment in the db.init code noting my idea in #18053
 of tweaking code to be explicit about when a DB is actually needed.

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

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

Re: [Django] #19172: test_poisoned_http_host* tests failing when having ADMINS settings populated

[Django]

#19172: test_poisoned_http_host* tests failing when having ADMINS settings
populated
-+-
 Reporter:  bernardofontes   |Owner:  claudep
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  unit tests, auth,| Triage Stage:  Accepted
  admin, mail|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by claudep):

 The test isolation thing is a design issue. I had proposed a patch (see
 #13394) to completely isolate tests based on a special testing class. Now
 I think that there is still an idea of doing some level of integration
 tests in contrib apps tests, so I'm unsure we really want to isolate
 contrib tests.

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

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

Re: [Django] #18865: Django connection getting lost in Interner Explorer

[Django]

#18865: Django connection getting lost  in Interner Explorer
-+-
 Reporter:  umits2009@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Django,Internet  | Triage Stage:
  Explorer   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I just noticed that you posted the exact same bug report some time ago in
 #18746.

 Don't do that, it's a waste of time for everyone.

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

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

Re: [Django] #18865: Django connection getting lost in Interner Explorer

[Django]

#18865: Django connection getting lost  in Interner Explorer
-+-
 Reporter:  umits2009@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Django,Internet  | Triage Stage:
  Explorer   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Old description:

> Hi Team,
>
> I ran into an issue while running my application.The connection between
> django and server is getting lost while I am clicking on a
> hyperlink.Because of this,session variables are getting out of scope.I am
> using Django 1.4.Python 2.7.
> This issue is coming only for IE.I tried in IE8 and IE9.
> PFB the logs for the same:
> Traceback (most recent call last):
>   File "C:\Python27\lib\wsgiref\handlers.py", line 86, in run
> self.finish_response()
>   File "C:\Python27\lib\wsgiref\handlers.py", line 127, in
> finish_response
> self.write(data)
>   File "C:\Python27\lib\wsgiref\handlers.py", line 210, in write
> self.send_headers()
>   File "C:\Python27\lib\wsgiref\handlers.py", line 266, in send_headers
> self.send_preamble()
>   File "C:\Python27\lib\wsgiref\handlers.py", line 189, in send_preamble
> self._write('HTTP/%s %s\r\n' % (self.http_version,self.status))
>   File "C:\Python27\lib\wsgiref\handlers.py", line 387, in _write
> self.stdout.write(data)
>   File "C:\Python27\lib\socket.py", line 322, in write
> self.flush()
>   File "C:\Python27\lib\socket.py", line 301, in flush
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
> error: [Errno 10054] An existing connection was forcibly closed by the
> remote ho
> st
> 
> Exception happened during processing of request from ('127.0.0.1', 60681)
> Traceback (most recent call last):
>   File "C:\Python27\lib\SocketServer.py", line 582, in
> process_request_thread
> self.finish_request(request, client_address)
>   File "C:\Python27\lib\SocketServer.py", line 323, in finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py",
> line 139
> , in __init__
> super(WSGIRequestHandler, self).__init__(*args, **kwargs)
>   File "C:\Python27\lib\SocketServer.py", line 641, in __init__
> self.finish()
>   File "C:\Python27\lib\SocketServer.py", line 694, in finish
> self.wfile.flush()
>   File "C:\Python27\lib\socket.py", line 301, in flush
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
> error: [Errno 10054] An existing connection was forcibly closed by the
> remote ho
> st
>
> Thanks,
> Umit

New description:

 Hi Team,

 I ran into an issue while running my application.The connection between
 django and server is getting lost while I am clicking on a
 hyperlink.Because of this,session variables are getting out of scope.I am
 using Django 1.4.Python 2.7.
 This issue is coming only for IE.I tried in IE8 and IE9.
 PFB the logs for the same:
 {{{
 Traceback (most recent call last):
   File "C:\Python27\lib\wsgiref\handlers.py", line 86, in run
 self.finish_response()
   File "C:\Python27\lib\wsgiref\handlers.py", line 127, in finish_response
 self.write(data)
   File "C:\Python27\lib\wsgiref\handlers.py", line 210, in write
 self.send_headers()
   File "C:\Python27\lib\wsgiref\handlers.py", line 266, in send_headers
 self.send_preamble()
   File "C:\Python27\lib\wsgiref\handlers.py", line 189, in send_preamble
 self._write('HTTP/%s %s\r\n' % (self.http_version,self.status))
   File "C:\Python27\lib\wsgiref\handlers.py", line 387, in _write
 self.stdout.write(data)
   File "C:\Python27\lib\socket.py", line 322, in write
 self.flush()
   File "C:\Python27\lib\socket.py", line 301, in flush
 self._sock.sendall(view[write_offset:write_offset+buffer_size])
 error: [Errno 10054] An existing connection was forcibly closed by the
 remote ho
 st
 
 Exception happened during processing of request from ('127.0.0.1', 60681)
 Traceback (most recent call last):
   File "C:\Python27\lib\SocketServer.py", line 582, in
 process_request_thread
 self.finish_request(request, client_address)
   File "C:\Python27\lib\SocketServer.py", line 323, in finish_request
 self.RequestHandlerClass(request, 

Re: [Django] #19023: Bug tracker spam filter is broken.

[Django]

#19023: Bug tracker spam filter is broken.
-+-
 Reporter:  tdhutt@… |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * version:  1.4 =>
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19043: Mutable Password Hash Strength

[Django]

#19043: Mutable Password Hash Strength
--+
 Reporter:  jbuckner  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  auth, bcrypt, pbkdf2  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 If I understand correctly, the technique described in the documentation to
 increase the work factor will only work for new passwords; existing
 passwords won't be upgraded. I'm accepting the ticket on this basis.

 However, I'd prefer an implementation based on subclassing, for the
 reasons described by ptone, and also because it's generally more flexible.

 The solution proposed by oinopion looks more like a workaround with the
 current code than like something we'd like to document.

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

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

Re: [Django] #18748: Remove dupe-avoidance logic from the ORM

[Django]

#18748: Remove dupe-avoidance logic from the ORM
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I have updated the patch. It consist of two major parts:
   - dupe avoidance removal
   - refactoring the signature and implementation of sql.Query.join()

 In a perfect world these should likely be two separate patches and
 tickets. However, I have the code ready in one patch, and I think now is a
 good time to commit this to master. Splitting this to two patches seems
 somewhat laborious for little benefit. The patch is still manageable in
 size.

 Code available in: https://github.com/akaariai/django/compare/ticket_18748

 The patch removes around 120 lines of code and adds 10 new comment lines.

 Unless objections I will commit this to master.

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

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

Re: [Django] #19073: strange behaviuor of select_related

[Django]

#19073: strange behaviuor of select_related
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 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 aaugustin):

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


Comment:

 Here's the result I get on master with the models described above:

 {{{
 >>> from test19073.models import *
 >>> D.objects.create()
 
 >>> D.objects.all()
 []
 >>> D.objects.select_related('b').all()
 []
 >>> D.objects.select_related('b', 'b__c').all()
 []
 >>> D.objects.select_related('b', 'b__c__a').all()
 []
 >>> D.objects.select_related('b', 'b__c__b').all()
 []
 }}}

 This bug may have been fixed after 1.4, or your report may be incomplete.

 Please reopen if you can reproduce the bug on master.

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

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

Re: [Django] #19159: loaddata reports DeserializationError instead of MemoryError

[Django]

#19159: loaddata reports DeserializationError instead of MemoryError
--+
 Reporter:  django@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19170: Add a way to control related fields reverse cache

[Django]

#19170: Add a way to control related fields reverse cache
-+-
 Reporter:  dirleyrls|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  orm realted cache|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In addition to the points made by Luke, I would add that this API creates
 "action at a distance". A developer would have to look at the model
 definition to understand the performance characteristics of the code he's
 working on (SQL queries are a huge factor in the performance of a Django
 application).

 I find it safer to always cache (I fixed several bugs in this area of
 Django), thereby minimizing SQL queries, and reload objects explicitly (or
 write your own APIs).

 For these reasons, I'm going to reject the API proposed in comment 2.

 PS: this isn't limited to backwards relations, the exact same arguments
 also apply to forward relations.

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

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

Re: [Django] #19173: "query" param for Model.objects.none() queryset has unexpected value.

[Django]

#19173: "query" param for Model.objects.none() queryset has unexpected value.
---+--
 Reporter:  joshua.fialkoff@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 Closing the ticket per Anssi's comment.

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

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

Re: [Django] #19181: Document caveats about using DateQuerySet in templates when time zone support is enabled.

[Django]

#19181: Document caveats about using DateQuerySet in templates when time zone
support is enabled.
-+--
 Reporter:  wiliamsouza83@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  docs | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by aaugustin):

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


Comment:

 Actually, your example still won't display the correct data, because the
 aggregation was performed in UTC and not in local time in the database.

 Generally speaking, I don't want to document workarounds, I want to fix
 this bug.

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

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

Re: [Django] #19161: Line missing on Dev documentation

[Django]

#19161: Line missing on Dev documentation
---+--
 Reporter:  DavidW |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Old description:

> https://docs.djangoproject.com/en/dev/topics/auth/#auth-custom-user
>
> class UserChangeForm(forms.ModelForm):
> """A form for updateing users. Includes all the fields on
> the user, but replaces the password field with admin's
> pasword hash display field.
> """
> password = ReadOnlyPasswordHashField()
>
> class Meta:
> model = MyUser
>
> Needs the following added:
>
> def clean_password(self):
> # Regardless of what the user provides, return the initial value.
> # This is done here, rather than on the field, because the
> # field does not have access to the initial value
> return self.initial["password"]
>
> Or you get a not-null constraint violation on form submit.

New description:

 https://docs.djangoproject.com/en/dev/topics/auth/#auth-custom-user

 {{{
 class UserChangeForm(forms.ModelForm):
 """A form for updateing users. Includes all the fields on
 the user, but replaces the password field with admin's
 pasword hash display field.
 """
 password = ReadOnlyPasswordHashField()

 class Meta:
 model = MyUser
 }}}

 Needs the following added:

 {{{
 def clean_password(self):
 # Regardless of what the user provides, return the initial value.
 # This is done here, rather than on the field, because the
 # field does not have access to the initial value
 return self.initial["password"]
 }}}

 Or you get a not-null constraint violation on form submit.

--

Comment (by aaugustin):

 Fixed formatting (please use preview).

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

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

Re: [Django] #19207: Typo translation

[Django]

#19207: Typo translation
---+--
 Reporter:  thanos@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Translations   |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  greek translation  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Thanks for the report, but Django translations are managed on Transifex:
 https://www.transifex.com/projects/p/django/language/el/

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

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

Re: [Django] #19172: test_poisoned_http_host* tests failing when having ADMINS settings populated

[Django]

#19172: test_poisoned_http_host* tests failing when having ADMINS settings
populated
-+-
 Reporter:  bernardofontes   |Owner:  claudep
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  unit tests, auth,| Triage Stage:  Accepted
  admin, mail|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by aaugustin):

 Once again, someone reports a test isolation problem, and we're going to
 hide the symptoms by overriding some settings rather than fix the root
 cause. It's not like I have a better short term solution to offer, though.

 I'd suggest adding a comment explaining why you chose to override
 `DEBUG_PROPAGATE_EXCEPTIONS` (and not, say, `ADMINS`).

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

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

Re: [Django] #19172: test_poisoned_http_host* tests failing when having ADMINS settings populated

[Django]

#19172: test_poisoned_http_host* tests failing when having ADMINS settings
populated
-+-
 Reporter:  bernardofontes   |Owner:  claudep
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  unit tests, auth,| Triage Stage:  Accepted
  admin, mail|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by claudep):

 * owner:  anonymous => claudep


Comment:

 I will apply the solution proposed in comment:7 if noone opposes.

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

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

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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


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

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

Re: [Django] #19205: HttpResponse docs refer to content_type, but shortcuts docs refer to mimetype

[Django]

#19205: HttpResponse docs refer to content_type, but shortcuts docs refer to
mimetype
---+--
 Reporter:  garrison   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 claudep):

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


Comment:

 This is not only a documentation change. See #10504

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

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

Re: [Django] #18964: defaultfilters test passes unexpectedly under Python 3

[Django]

#18964: defaultfilters test passes unexpectedly under Python 3
-+-
 Reporter:  russellm |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  python3  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"8d7e526229c27567860f7479dbce15d245742feb"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d7e526229c27567860f7479dbce15d245742feb"
 [1.5.x] Fixed #18964 -- floatformat test passes under py3k

 Thanks Russell for the report.

 Backport of b4420d9 from master.
 }}}

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

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

[django/django] 8d7e52: [1.5.x] Fixed #18964 -- floatformat test passes un...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 8d7e526229c27567860f7479dbce15d245742feb
  
https://github.com/django/django/commit/8d7e526229c27567860f7479dbce15d245742feb
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

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

  Log Message:
  ---
  [1.5.x] Fixed #18964 -- floatformat test passes under py3k

Thanks Russell for the report.

Backport of b4420d9 from master.



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

[django/django] b4420d: Fixed #18964 -- floatformat test passes under py3k

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b4420d96023b9d9067ebc8e8dcd8ca7cea41aff1
  
https://github.com/django/django/commit/b4420d96023b9d9067ebc8e8dcd8ca7cea41aff1
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

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

  Log Message:
  ---
  Fixed #18964 -- floatformat test passes under py3k

Thanks Russell for the report.



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

Re: [Django] #18964: defaultfilters test passes unexpectedly under Python 3

[Django]

#18964: defaultfilters test passes unexpectedly under Python 3
-+-
 Reporter:  russellm |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  python3  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 The test that unexpectedly passes is:
 {{{
 self.assertEqual(floatformat(1.00015, 16),
 '1.0002')
 }}}

 Under Python 2, it returns `'1.'`.

 

 The explanation is pretty simple.

 The first step of the `floatformat` template filter is to coerce its input
 as text, and this step introduces the difference between Python 2 and
 Python 3.

 {{{
 % python2.6
 >>> 1.00015
 1.0002
 >>> str(_)
 '1.0'
 }}}

 {{{
 % python3.2
 >>> 1.00015
 1.0002
 >>> str(_)
 '1.0002'
 }}}

 I think it's related to this paragraph of
 [http://docs.python.org/3.1/whatsnew/3.1.html Python 3.1's release notes]:

 > Python now uses David Gay’s algorithm for finding the shortest floating
 point representation that doesn’t change its value.

 

 Arguably, this is a bug in Python 2 that was fixed in Python 3. I'm going
 to mark the test as an expected failure only on Python 2.

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

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

[Django] #19207: Typo translation

[Django]

#19207: Typo translation
---+---
 Reporter:  thanos@...   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Translations   |Version:  1.4
 Severity:  Normal |   Keywords:  greek translation
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+---
 File: conf/locale/el/LC_MESSAGES/django.po
 Line: 761

 #:forms/widgets.py:327
 msgid "Clear"
 msgstr "Εκκαθάσριση"

 The greek word should be:  "Εκκαθάριση"
 As noted by D. Thilikos.

 Single-line patch:

 761c761
 < msgstr "Εκκαθάσριση"
 ---
 > msgstr "Εκκαθάριση"

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

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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | 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 aaugustin):

 Claude's latest patch looks good. I'd like to hear from the people
 involved on #16873 before making a decision.

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

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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | 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 aaugustin):

 This ticket essentially re-opens #16873.

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

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

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
-+-
 Reporter:  delormemarco@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  reopened => new


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

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

Re: [Django] #18964: defaultfilters test passes unexpectedly under Python 3

[Django]

#18964: defaultfilters test passes unexpectedly under Python 3
-+-
 Reporter:  russellm |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  python3  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


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

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

Re: [Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

[Django]

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
--+
 Reporter:  charles@… |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #19201: session data should always contain the expiry date

[Django]

#19201: session data should always contain the expiry date
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.sessions |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"58337b32236eb57d82bf62ed077add3ec69e37f2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="58337b32236eb57d82bf62ed077add3ec69e37f2"
 Marked cookies-based session expiry test as an expected failure.

 Refs #19201.
 }}}

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

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

Re: [Django] #19201: session data should always contain the expiry date

[Django]

#19201: session data should always contain the expiry date
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.sessions |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"88393357a6839fb4ce57793523bc25b17dc188a4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="88393357a6839fb4ce57793523bc25b17dc188a4"
 [1.5.x] Marked cookies-based session expiry test as an expected failure.

 Refs #19201.

 Backport of 58337b3 from master.
 }}}

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

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

[django/django] 58a086: Required serializer to use bytes in loads/dumps

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 58a086acfbec833f44cd53e984972250bbb67457
  
https://github.com/django/django/commit/58a086acfbec833f44cd53e984972250bbb67457
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/core/signing.py

  Log Message:
  ---
  Required serializer to use bytes in loads/dumps

loads has no way to tell if it should provide text or bytes to the
serializer; bytes are more reasonnable for a serialized representation,
and are the only option for pickled data.

dumps can perform conversions on the value it receives from the
serializer; but for consistency it seems better to require bytes too.

The current code would cause an exception when loading pickled session
data. See next commit.

Also fixed a bug when checking for compressed data.


  Commit: 58337b32236eb57d82bf62ed077add3ec69e37f2
  
https://github.com/django/django/commit/58337b32236eb57d82bf62ed077add3ec69e37f2
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/tests.py

  Log Message:
  ---
  Marked cookies-based session expiry test as an expected failure.

Refs #19201.


Compare: https://github.com/django/django/compare/611c4d6f1c24...58337b32236e

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

[django/django] 780eaa: [1.5.x] Required serializer to use bytes in loads/...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 780eaa4779c5e6bd6bdc2c34e71aeae5d1b0dbbd
  
https://github.com/django/django/commit/780eaa4779c5e6bd6bdc2c34e71aeae5d1b0dbbd
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/core/signing.py

  Log Message:
  ---
  [1.5.x] Required serializer to use bytes in loads/dumps

loads has no way to tell if it should provide text or bytes to the
serializer; bytes are more reasonnable for a serialized representation,
and are the only option for pickled data.

dumps can perform conversions on the value it receives from the
serializer; but for consistency it seems better to require bytes too.

The current code would cause an exception when loading pickled session
data. See next commit.

Also fixed a bug when checking for compressed data.

Backport of 58a086a from master.


  Commit: 88393357a6839fb4ce57793523bc25b17dc188a4
  
https://github.com/django/django/commit/88393357a6839fb4ce57793523bc25b17dc188a4
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/tests.py

  Log Message:
  ---
  [1.5.x] Marked cookies-based session expiry test as an expected failure.

Refs #19201.

Backport of 58337b3 from master.


Compare: https://github.com/django/django/compare/f105fbe52b21...88393357a683

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

Re: [Django] #10899: easier manipulation of sessions by test client

[Django]

#10899: easier manipulation of sessions by test client
---+
 Reporter:  tallfred   |Owner:  nobody
 Type:  New feature|   Status:  reopened
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by kitsunde):

 * cc: kitsunde@… (added)


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

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

Re: [Django] #11475: test.Client.session.save() raises error for anonymous users

[Django]

#11475: test.Client.session.save() raises error for anonymous users
---+--
 Reporter:  egmanoj@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.1-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kitsunde):

 * cc: kitsunde@… (added)


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

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

Re: [Django] #18823: Clear with a M2M field with a through model

[Django]

#18823: Clear with a M2M field with a through model
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

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

 In [changeset:"37c87b785da934815f1f5ca863d88ac0685bff2a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="37c87b785da934815f1f5ca863d88ac0685bff2a"
 [1.4.x] Fixed #18823 -- Ensured m2m.clear() works when using
 through+to_field

 There was a potential data-loss issue involved -- when clearing
 instance's m2m assignments it was possible some other instance's
 m2m data was deleted instead.

 This commit also improved None handling for to_field cases.

 Backpatch of 611c4d6f1c24763e5e6e331a5dcf9b610288aaa8
 }}}

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

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

[django/django] 37c87b: [1.4.x] Fixed #18823 -- Ensured m2m.clear() works ...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 37c87b785da934815f1f5ca863d88ac0685bff2a
  
https://github.com/django/django/commit/37c87b785da934815f1f5ca863d88ac0685bff2a
  Author: Anssi Kääriäinen 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

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

  Log Message:
  ---
  [1.4.x] Fixed #18823 -- Ensured m2m.clear() works when using through+to_field

There was a potential data-loss issue involved -- when clearing
instance's m2m assignments it was possible some other instance's
m2m data was deleted instead.

This commit also improved None handling for to_field cases.

Backpatch of 611c4d6f1c24763e5e6e331a5dcf9b610288aaa8



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

Re: [Django] #18823: Clear with a M2M field with a through model

[Django]

#18823: Clear with a M2M field with a through model
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

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

 In [changeset:"f105fbe52b21da206bfbaedf0e92326667d7b2d4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f105fbe52b21da206bfbaedf0e92326667d7b2d4"
 [1.5.x] Fixed #18823 -- Ensured m2m.clear() works when using
 through+to_field

 There was a potential data-loss issue involved -- when clearing
 instance's m2m assignments it was possible some other instance's
 m2m data was deleted instead.

 This commit also improved None handling for to_field cases.

 Backpatch of 611c4d6f1c24763e5e6e331a5dcf9b610288aaa8
 }}}

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

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

[django/django] f105fb: [1.5.x] Fixed #18823 -- Ensured m2m.clear() works ...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: f105fbe52b21da206bfbaedf0e92326667d7b2d4
  
https://github.com/django/django/commit/f105fbe52b21da206bfbaedf0e92326667d7b2d4
  Author: Anssi Kääriäinen 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

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

  Log Message:
  ---
  [1.5.x] Fixed #18823 -- Ensured m2m.clear() works when using through+to_field

There was a potential data-loss issue involved -- when clearing
instance's m2m assignments it was possible some other instance's
m2m data was deleted instead.

This commit also improved None handling for to_field cases.

Backpatch of 611c4d6f1c24763e5e6e331a5dcf9b610288aaa8



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

Re: [Django] #18823: Clear with a M2M field with a through model

[Django]

#18823: Clear with a M2M field with a through model
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"611c4d6f1c24763e5e6e331a5dcf9b610288aaa8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="611c4d6f1c24763e5e6e331a5dcf9b610288aaa8"
 Fixed #18823 -- Ensured m2m.clear() works when using through+to_field

 There was a potential data-loss issue involved -- when clearing
 instance's m2m assignments it was possible some other instance's
 m2m data was deleted instead.

 This commit also improved None handling for to_field cases.
 }}}

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

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

[django/django] 611c4d: Fixed #18823 -- Ensured m2m.clear() works when usi...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 611c4d6f1c24763e5e6e331a5dcf9b610288aaa8
  
https://github.com/django/django/commit/611c4d6f1c24763e5e6e331a5dcf9b610288aaa8
  Author: Anssi Kääriäinen 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

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

  Log Message:
  ---
  Fixed #18823 -- Ensured m2m.clear() works when using through+to_field

There was a potential data-loss issue involved -- when clearing
instance's m2m assignments it was possible some other instance's
m2m data was deleted instead.

This commit also improved None handling for to_field cases.



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

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
---+--
 Reporter:  apollo13   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 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 lrekucki):

 At some point, I was thinking about adding `suffix=__module__` (apart from
 `prefix=django`) to every `tmpdir`/`tmpfile` call, so it's easier to track
 which test didn't cleanup. Do you think it's a good idea?

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

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

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
---+--
 Reporter:  apollo13   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 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 d1ffuz0r):

 In tests don't exit from selenium at end of tests. need use
 selenium.quit() for to close session

 (django)django|master => grep -rl selenium.close tests
 (django)django|master => grep -rl selenium.quit tests
 (django)django|master =>

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

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

Re: [Django] #14093: Confusing error when failing to create a session key because the cache is unavailable

[Django]

#14093: Confusing error when failing to create a session key because the cache 
is
unavailable
-+-
 Reporter:  szymon@… |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session, cache,  | Triage Stage:  Accepted
  session key|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"98032f67c725e257bd3c53374ff0ee22e2c77d7c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="98032f67c725e257bd3c53374ff0ee22e2c77d7c"
 Fixed #14093 -- Improved error message in the cache session backend.

 Thanks stumbles for the patch.
 }}}

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

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

[django/django] 98032f: Fixed #14093 -- Improved error message in the cach...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 98032f67c725e257bd3c53374ff0ee22e2c77d7c
  
https://github.com/django/django/commit/98032f67c725e257bd3c53374ff0ee22e2c77d7c
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/backends/cache.py

  Log Message:
  ---
  Fixed #14093 -- Improved error message in the cache session backend.

Thanks stumbles for the patch.



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

Re: [Django] #16039: syncdb with --database option fails

[Django]

#16039: syncdb with --database option fails
-+-
 Reporter:  yedpodtrzitko|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I am beginning to think that if you get any contenttypes to a DB, then you
 might want them all. For example users will likely want to store all
 permissions in one database (the database which contains the Users and
 Groups data). Even permissions for models which are not synced to the
 default database, so that there is one DB to ask for all permissions. But,
 if we install all permissions to a database, then we need all ContentTypes
 there too.

 The "sync only those contenttypes whose model is in the DB" seems useful
 for one use case - GenericForeignKeys. But that isn't the only use case.
 And, installing additional ContetTypes into a DB seems safe to me.

 This ticket has potential for endless amounts of complexity. MultiDB is
 complex. In addition we don't have information about the use case, nor do
 we know essential information: for example in master-slave setup we don't
 know which DB is the master...

 So, another proposal for solution:
   - Sync _all_ contenttypes and permissions to default database (this is
 essentially what is happening now)
   - No sync at all for other databases

 The proposal isn't the ultimate right solution. But it is simple and safe.
 With the information at hand at sync time doing anything smarter might be
 hard, too.

 I am not a multidb expert at all. But, if this ticket doesn't get a
 solution from others for 1.5, then I am going to go with the simple
 solution.

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

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

[django/django] 13b4d4: [1.5.x] Reverted unintentional change in aff9b2f.

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 13b4d44860ebdfa3b5b2a0cb338013aff86ccdf8
  
https://github.com/django/django/commit/13b4d44860ebdfa3b5b2a0cb338013aff86ccdf8
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py

  Log Message:
  ---
  [1.5.x] Reverted unintentional change in aff9b2f.

Backport of 785bf0d from master.



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

[django/django] 785bf0: Reverted unintentional change in aff9b2f.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 785bf0d5a04d8466091a701b732b0c6f87b548e4
  
https://github.com/django/django/commit/785bf0d5a04d8466091a701b732b0c6f87b548e4
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py

  Log Message:
  ---
  Reverted unintentional change in aff9b2f.



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

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
---+--
 Reporter:  apollo13   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 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
---+--
Description changed by apollo13:

Old description:

> As seen on the ci, Django's testsuite leaves some data behind:
> {{{
> 4.1k./django_Esgc5K/tmpuI9dnf
> 8.2k./django_Esgc5K/tmpeTp_A1/tests
> 8.2k./django_Esgc5K/tmpeTp_A1/foo
> 21k ./django_Esgc5K/tmpeTp_A1
> 4.1k./django_Esgc5K/tmp5wdSuu
> 33k ./django_Esgc5K
> 37k ./tmpSyauUn/x86
> 41k ./tmpSyauUn/amd64
> 4.1k./tmpSyauUn/minidumps
> 779k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource/modules
> 816k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource
> 2.5M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3/components
> 2.5M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3
> 1.4M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc/components
> 1.4M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc
> 2.6M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3/components
> 2.6M
> ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3
> 6.4M./tmpSyauUn/extensions/fxdri...@googlecode.com/platform
> 25k ./tmpSyauUn/extensions/fxdri...@googlecode.com/content
> 2.9M./tmpSyauUn/extensions/fxdri...@googlecode.com/components
> 11M ./tmpSyauUn/extensions/fxdri...@googlecode.com
> 11M ./tmpSyauUn/extensions
> 4.1k./tmpSyauUn/webapps
> 8.2k./tmpSyauUn/bookmarkbackups
> 4.1k./tmpSyauUn/Cache/D
> 4.1k./tmpSyauUn/Cache/2
> 4.1k./tmpSyauUn/Cache/A
> 4.1k./tmpSyauUn/Cache/1
> 4.1k./tmpSyauUn/Cache/7
> 4.1k./tmpSyauUn/Cache/6
> 4.1k./tmpSyauUn/Cache/0
> 4.1k./tmpSyauUn/Cache/F
> 4.1k./tmpSyauUn/Cache/8
> 4.1k./tmpSyauUn/Cache/4
> 4.1k./tmpSyauUn/Cache/E
> 4.1k./tmpSyauUn/Cache/C
> 4.1k./tmpSyauUn/Cache/B
> 4.1k./tmpSyauUn/Cache/5
> 4.1k./tmpSyauUn/Cache/9
> 4.1k./tmpSyauUn/Cache/3
> 111k./tmpSyauUn/Cache
> 4.1k./tmpSyauUn/startupCache
> 29M ./tmpSyauUn
> 4.1k./tmpz38m5u
> 37k ./hsperfdata_jenkins
> 11M ./tmpjTVehh/test_upload
> 11M ./tmpjTVehh
> 11M ./tmpgeUZWe/test_upload
> 11M ./tmpgeUZWe
> }}}
>
> ''extensions/fxdri...@googlecode.com'' seems to be coming from selenium,
> but the rest is from us, we should try to get rid of those!

New description:

 As seen on the ci, Django's testsuite leaves some data behind:
 {{{
 4.1k./django_Esgc5K/tmpuI9dnf
 8.2k./django_Esgc5K/tmpeTp_A1/tests
 8.2k./django_Esgc5K/tmpeTp_A1/foo
 21k ./django_Esgc5K/tmpeTp_A1
 4.1k./django_Esgc5K/tmp5wdSuu
 33k ./django_Esgc5K
 37k ./tmpSyauUn/x86
 41k ./tmpSyauUn/amd64
 4.1k./tmpSyauUn/minidumps
 779k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource/modules
 816k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource
 2.5M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3/components
 2.5M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3
 1.4M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc/components
 1.4M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc
 2.6M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3/components
 2.6M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3
 6.4M./tmpSyauUn/extensions/fxdri...@googlecode.com/platform
 25k ./tmpSyauUn/extensions/fxdri...@googlecode.com/content
 2.9M./tmpSyauUn/extensions/fxdri...@googlecode.com/components
 11M ./tmpSyauUn/extensions/fxdri...@googlecode.com
 11M ./tmpSyauUn/extensions
 4.1k./tmpSyauUn/webapps
 8.2k./tmpSyauUn/bookmarkbackups
 4.1k./tmpSyauUn/Cache/D
 4.1k./tmpSyauUn/Cache/2
 4.1k./tmpSyauUn/Cache/A
 4.1k./tmpSyauUn/Cache/1
 4.1k./tmpSyauUn/Cache/7
 4.1k./tmpSyauUn/Cache/6
 4.1k./tmpSyauUn/Cache/0
 4.1k./tmpSyauUn/Cache/F
 4.1k./tmpSyauUn/Cache/8
 4.1k./tmpSyauUn/Cache/4
 4.1k./tmpSyauUn/Cache/E
 4.1k./tmpSyauUn/Cache/C
 4.1k./tmpSyauUn/Cache/B
 4.1k./tmpSyauUn/Cache/5
 4.1k./tmpSyauUn/Cache/9
 4.1k./tmpSyauUn/Cache/3
 111k./tmpSyauUn/Cache
 4.1k./tmpSyauUn/startupCache
 29M ./tmpSyauUn
 4.1k./tmpz38m5u
 37k 

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
---+--
 Reporter:  apollo13   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 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 apollo13):

 The selenium part of the tests is now fixed by upgrading selenium on the
 buildserver.

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

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

Re: [Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
---+--
 Reporter:  lgx@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  find_commands  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by russellm):

 I can appreciate the situation you're in here, but @carljm's point is
 entirely valid - PYC files aren't "compiled python" (or, at least, they
 shouldn't be treated like that). They're a cache of the runtime operation
 of a language interpreter -- an artefact that varies between language
 implementations and versions.

 In this case, what you're faced with are legal requirements, rather than
 technical ones. If Brazilian law specifically uses words like
 "executable", then whoever drafted the law clearly didn't anticipate
 dynamic languages like Python. While this is unfortunate, it's
 unreasonable to expect us to modify the project to accommodate a non-
 recommended use of Python just to satisfy your interpretation of a
 Brazilian legal requirement.

 In the short term, I'd suggest trying to work around the law. Get legal
 advice about *exactly* what must be signed in order to be compliant. Have
 you actually got legal advice that declares that in the case of Python,
 the .pyc file *is* the executable? I'm not a lawyer, and I have no
 familiarity with the PAF-ECF law, but if it says you need to sign the
 "executable", then is there any scope for you to sign the *Python*
 executable and say you've met your requirement? Could you sign the .py
 file, on the grounds that *it* is the executable? Could you sign an egg
 file that contains the source code? These are all questions that you'd
 need to get legal advice on to be certain, but from my past experience,
 the way that an engineer chooses to interpret the law doesn't always match
 the way that a lawyer or judge would consider compliant usage.

 In the longer term, work to fix the law. Work with your representatives to
 get the wording altered in a way that is compatible with dynamic
 languages. This is the industry you work in, so you need to take an
 interest when governments start passing boneheaded laws that don't match
 industry practice.

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

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

Re: [Django] #17869: With RemoteUserMiddleware, users keep being logged in after web server stops sending REMOTE_USER headers

[Django]

#17869: With RemoteUserMiddleware, users keep being logged in after web server
stops sending REMOTE_USER headers
-+
 Reporter:  lamby|Owner:  ptone
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by aaugustin):

 It would be better to use `auth.BACKEND_SESSION_KEY`, as in
 `clean_username`, than to redefine `BACKEND_SESSION_KEY` in this module.

 Otherwise, this looks good to me.

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

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

[Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
-+
   Reporter:  apollo13   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 As seen on the ci, Django's testsuite leaves some data behind:
 {{{
 4.1k./django_Esgc5K/tmpuI9dnf
 8.2k./django_Esgc5K/tmpeTp_A1/tests
 8.2k./django_Esgc5K/tmpeTp_A1/foo
 21k ./django_Esgc5K/tmpeTp_A1
 4.1k./django_Esgc5K/tmp5wdSuu
 33k ./django_Esgc5K
 37k ./tmpSyauUn/x86
 41k ./tmpSyauUn/amd64
 4.1k./tmpSyauUn/minidumps
 779k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource/modules
 816k./tmpSyauUn/extensions/fxdri...@googlecode.com/resource
 2.5M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3/components
 2.5M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86-gcc3
 1.4M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc/components
 1.4M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/WINNT_x86-msvc
 2.6M
 
./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3/components
 2.6M
 ./tmpSyauUn/extensions/fxdri...@googlecode.com/platform/Linux_x86_64-gcc3
 6.4M./tmpSyauUn/extensions/fxdri...@googlecode.com/platform
 25k ./tmpSyauUn/extensions/fxdri...@googlecode.com/content
 2.9M./tmpSyauUn/extensions/fxdri...@googlecode.com/components
 11M ./tmpSyauUn/extensions/fxdri...@googlecode.com
 11M ./tmpSyauUn/extensions
 4.1k./tmpSyauUn/webapps
 8.2k./tmpSyauUn/bookmarkbackups
 4.1k./tmpSyauUn/Cache/D
 4.1k./tmpSyauUn/Cache/2
 4.1k./tmpSyauUn/Cache/A
 4.1k./tmpSyauUn/Cache/1
 4.1k./tmpSyauUn/Cache/7
 4.1k./tmpSyauUn/Cache/6
 4.1k./tmpSyauUn/Cache/0
 4.1k./tmpSyauUn/Cache/F
 4.1k./tmpSyauUn/Cache/8
 4.1k./tmpSyauUn/Cache/4
 4.1k./tmpSyauUn/Cache/E
 4.1k./tmpSyauUn/Cache/C
 4.1k./tmpSyauUn/Cache/B
 4.1k./tmpSyauUn/Cache/5
 4.1k./tmpSyauUn/Cache/9
 4.1k./tmpSyauUn/Cache/3
 111k./tmpSyauUn/Cache
 4.1k./tmpSyauUn/startupCache
 29M ./tmpSyauUn
 4.1k./tmpz38m5u
 37k ./hsperfdata_jenkins
 11M ./tmpjTVehh/test_upload
 11M ./tmpjTVehh
 11M ./tmpgeUZWe/test_upload
 11M ./tmpgeUZWe
 }}}

 ''extensions/fxdri...@googlecode.com'' seems to be coming from selenium,
 but the rest is from us, we should try to get rid of those!

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

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

Re: [Django] #19203: Test failing when pytz not installed and not in "America/Chicago"

[Django]

#19203: Test failing when pytz not installed and not in "America/Chicago"
--+--
 Reporter:  lrekucki  |Owner:  aaugustin
 Type:  Uncategorized |   Status:  closed
Component:  contrib.humanize  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"54b45dfb5384e5db24932b0d183b226c990d23ed"]:
 {{{
 #!CommitTicketReference repository=""
 revision="54b45dfb5384e5db24932b0d183b226c990d23ed"
 [1.5.x] Fixed #19203 -- Added isolation to a humanize test

 Thanks lrekucki for the report.

 Backport of aff9b2f from master.
 }}}

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

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

[django/django] 54b45d: [1.5.x] Fixed #19203 -- Added isolation to a human...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 54b45dfb5384e5db24932b0d183b226c990d23ed
  
https://github.com/django/django/commit/54b45dfb5384e5db24932b0d183b226c990d23ed
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py
M django/contrib/humanize/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19203 -- Added isolation to a humanize test

Thanks lrekucki for the report.

Backport of aff9b2f from master.



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

Re: [Django] #19203: Test failing when pytz not installed and not in "America/Chicago"

[Django]

#19203: Test failing when pytz not installed and not in "America/Chicago"
--+--
 Reporter:  lrekucki  |Owner:  aaugustin
 Type:  Uncategorized |   Status:  closed
Component:  contrib.humanize  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 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 Aymeric Augustin ):

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


Comment:

 In [changeset:"aff9b2f5662f8a007bb90a427190c0d573a3ba65"]:
 {{{
 #!CommitTicketReference repository=""
 revision="aff9b2f5662f8a007bb90a427190c0d573a3ba65"
 Fixed #19203 -- Added isolation to a humanize test

 Thanks lrekucki 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] aff9b2: Fixed #19203 -- Added isolation to a humanize test

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: aff9b2f5662f8a007bb90a427190c0d573a3ba65
  
https://github.com/django/django/commit/aff9b2f5662f8a007bb90a427190c0d573a3ba65
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/conf/global_settings.py
M django/contrib/humanize/tests.py

  Log Message:
  ---
  Fixed #19203 -- Added isolation to a humanize test

Thanks lrekucki for the report.



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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"39082494e62d70be62cde1eb10620548fd62dfb6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="39082494e62d70be62cde1eb10620548fd62dfb6"
 [1.5.x] Fixed #18194 -- Expiration of file-based sessions

 * Prevented stale session files from being loaded
 * Added removal of stale session files in django-admin.py clearsessions

 Thanks ej for the report, crodjer and Elvard for their inputs.

 Backport of 5fec97b from master.
 }}}

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

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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6"
 [1.5.x] Improved tests introduced in 04b00b6.

 These tests are expected to fail for the file session backend because it
 doesn't handle expiry properly. They didn't because of an error in the
 test setup sequence.

 Refs #19200, #18194.

 Backport of 882c47c from master.
 }}}

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

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

Re: [Django] #19200: cached_db backend doesn't honor expiry time

[Django]

#19200: cached_db backend doesn't honor expiry time
--+--
 Reporter:  aaugustin |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6"
 [1.5.x] Improved tests introduced in 04b00b6.

 These tests are expected to fail for the file session backend because it
 doesn't handle expiry properly. They didn't because of an error in the
 test setup sequence.

 Refs #19200, #18194.

 Backport of 882c47c from master.
 }}}

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

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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f"
 [1.5.x] Added optional kwargs to get_expiry_age/date.

 This change allows for cleaner tests: we can test the exact output.

 Refs #18194: this change makes it possible to compute session expiry
 dates at times other than when the session is saved.

 Fixed #18458: the existence of the `modification` kwarg implies that you
 must pass it to get_expiry_age/date if you call these functions outside
 of a short request - response cycle (the intended use case).

 Backport of cd17a24 from master.
 }}}

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

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

Re: [Django] #18458: Method session.get_expiry_age() does not return what the doc says

[Django]

#18458: Method session.get_expiry_age() does not return what the doc says
-+-
 Reporter:  martin.bouladour@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session expiration   | Triage Stage:  Accepted
  expiry age get_expiry_age  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f"
 [1.5.x] Added optional kwargs to get_expiry_age/date.

 This change allows for cleaner tests: we can test the exact output.

 Refs #18194: this change makes it possible to compute session expiry
 dates at times other than when the session is saved.

 Fixed #18458: the existence of the `modification` kwarg implies that you
 must pass it to get_expiry_age/date if you call these functions outside
 of a short request - response cycle (the intended use case).

 Backport of cd17a24 from master.
 }}}

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

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

[django/django] 845d84: [1.5.x] Added optional kwargs to get_expiry_age/da...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f
  
https://github.com/django/django/commit/845d8408e7aa09a63c98f160b2c6bc9fa6dbb20f
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/cached_db.py
M django/contrib/sessions/tests.py
M docs/topics/http/sessions.txt

  Log Message:
  ---
  [1.5.x] Added optional kwargs to get_expiry_age/date.

This change allows for cleaner tests: we can test the exact output.

Refs #18194: this change makes it possible to compute session expiry
dates at times other than when the session is saved.

Fixed #18458: the existence of the `modification` kwarg implies that you
must pass it to get_expiry_age/date if you call these functions outside
of a short request - response cycle (the intended use case).

Backport of cd17a24 from master.


  Commit: e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6
  
https://github.com/django/django/commit/e6b0ee768c46368a41a5b278180d1d1ecbd3d5c6
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/tests.py

  Log Message:
  ---
  [1.5.x] Improved tests introduced in 04b00b6.

These tests are expected to fail for the file session backend because it
doesn't handle expiry properly. They didn't because of an error in the
test setup sequence.

Refs #19200, #18194.

Backport of 882c47c from master.


  Commit: 39082494e62d70be62cde1eb10620548fd62dfb6
  
https://github.com/django/django/commit/39082494e62d70be62cde1eb10620548fd62dfb6
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/cache.py
M django/contrib/sessions/backends/db.py
M django/contrib/sessions/backends/file.py
M django/contrib/sessions/backends/signed_cookies.py
M django/contrib/sessions/management/commands/clearsessions.py
M django/contrib/sessions/tests.py
M docs/ref/django-admin.txt
M docs/topics/http/sessions.txt

  Log Message:
  ---
  [1.5.x] Fixed #18194 -- Expiration of file-based sessions

* Prevented stale session files from being loaded
* Added removal of stale session files in django-admin.py clearsessions

Thanks ej for the report, crodjer and Elvard for their inputs.

Backport of 5fec97b from master.


Compare: https://github.com/django/django/compare/c5da577b9e39...39082494e62d

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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  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 Aymeric Augustin ):

 In [changeset:"882c47cd405cfd29194f2e968678a5aa1d6ec75f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="882c47cd405cfd29194f2e968678a5aa1d6ec75f"
 Improved tests introduced in 04b00b6.

 These tests are expected to fail for the file session backend because it
 doesn't handle expiry properly. They didn't because of an error in the
 test setup sequence.

 Refs #19200, #18194.
 }}}

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

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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"5fec97b9df6ea075483276de159e522a29437773"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5fec97b9df6ea075483276de159e522a29437773"
 Fixed #18194 -- Expiration of file-based sessions

 * Prevented stale session files from being loaded
 * Added removal of stale session files in django-admin.py clearsessions

 Thanks ej for the report, crodjer and Elvard for their inputs.
 }}}

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

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

Re: [Django] #19200: cached_db backend doesn't honor expiry time

[Django]

#19200: cached_db backend doesn't honor expiry time
--+--
 Reporter:  aaugustin |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Aymeric Augustin ):

 In [changeset:"882c47cd405cfd29194f2e968678a5aa1d6ec75f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="882c47cd405cfd29194f2e968678a5aa1d6ec75f"
 Improved tests introduced in 04b00b6.

 These tests are expected to fail for the file session backend because it
 doesn't handle expiry properly. They didn't because of an error in the
 test setup sequence.

 Refs #19200, #18194.
 }}}

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

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

Re: [Django] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
-+-
 Reporter:  ej   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  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 Aymeric Augustin ):

 In [changeset:"cd17a24083f3ef17cf4c40a41c9d03c250d817c6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cd17a24083f3ef17cf4c40a41c9d03c250d817c6"
 Added optional kwargs to get_expiry_age/date.

 This change allows for cleaner tests: we can test the exact output.

 Refs #18194: this change makes it possible to compute session expiry
 dates at times other than when the session is saved.

 Fixed #18458: the existence of the `modification` kwarg implies that you
 must pass it to get_expiry_age/date if you call these functions outside
 of a short request - response cycle (the intended 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18458: Method session.get_expiry_age() does not return what the doc says

[Django]

#18458: Method session.get_expiry_age() does not return what the doc says
-+-
 Reporter:  martin.bouladour@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session expiration   | Triage Stage:  Accepted
  expiry age get_expiry_age  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"cd17a24083f3ef17cf4c40a41c9d03c250d817c6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cd17a24083f3ef17cf4c40a41c9d03c250d817c6"
 Added optional kwargs to get_expiry_age/date.

 This change allows for cleaner tests: we can test the exact output.

 Refs #18194: this change makes it possible to compute session expiry
 dates at times other than when the session is saved.

 Fixed #18458: the existence of the `modification` kwarg implies that you
 must pass it to get_expiry_age/date if you call these functions outside
 of a short request - response cycle (the intended 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] cd17a2: Added optional kwargs to get_expiry_age/date.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: cd17a24083f3ef17cf4c40a41c9d03c250d817c6
  
https://github.com/django/django/commit/cd17a24083f3ef17cf4c40a41c9d03c250d817c6
  Author: Aymeric Augustin 
  Date:   2012-10-27 (Sat, 27 Oct 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/cached_db.py
M django/contrib/sessions/tests.py
M docs/topics/http/sessions.txt

  Log Message:
  ---
  Added optional kwargs to get_expiry_age/date.

This change allows for cleaner tests: we can test the exact output.

Refs #18194: this change makes it possible to compute session expiry
dates at times other than when the session is saved.

Fixed #18458: the existence of the `modification` kwarg implies that you
must pass it to get_expiry_age/date if you call these functions outside
of a short request - response cycle (the intended use case).


  Commit: 882c47cd405cfd29194f2e968678a5aa1d6ec75f
  
https://github.com/django/django/commit/882c47cd405cfd29194f2e968678a5aa1d6ec75f
  Author: Aymeric Augustin 
  Date:   2012-10-27 (Sat, 27 Oct 2012)

  Changed paths:
M django/contrib/sessions/tests.py

  Log Message:
  ---
  Improved tests introduced in 04b00b6.

These tests are expected to fail for the file session backend because it
doesn't handle expiry properly. They didn't because of an error in the
test setup sequence.

Refs #19200, #18194.


  Commit: 5fec97b9df6ea075483276de159e522a29437773
  
https://github.com/django/django/commit/5fec97b9df6ea075483276de159e522a29437773
  Author: Aymeric Augustin 
  Date:   2012-10-28 (Sun, 28 Oct 2012)

  Changed paths:
M django/contrib/sessions/backends/base.py
M django/contrib/sessions/backends/cache.py
M django/contrib/sessions/backends/db.py
M django/contrib/sessions/backends/file.py
M django/contrib/sessions/backends/signed_cookies.py
M django/contrib/sessions/management/commands/clearsessions.py
M django/contrib/sessions/tests.py
M docs/ref/django-admin.txt
M docs/topics/http/sessions.txt

  Log Message:
  ---
  Fixed #18194 -- Expiration of file-based sessions

* Prevented stale session files from being loaded
* Added removal of stale session files in django-admin.py clearsessions

Thanks ej for the report, crodjer and Elvard for their inputs.


Compare: https://github.com/django/django/compare/fc2681b22b12...5fec97b9df6e

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

Re: [Django] #19203: Test failing when pytz not installed and not in "America/Chicago"

[Django]

#19203: Test failing when pytz not installed and not in "America/Chicago"
--+--
 Reporter:  lrekucki  |Owner:  aaugustin
 Type:  Uncategorized |   Status:  new
Component:  contrib.humanize  |  Version:  1.4
 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 aaugustin):

 * owner:  nobody => aaugustin


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

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

Re: [Django] #19204: Python2-style exception syntax is still used in django.utils.unittest (and should be updated)

[Django]

#19204: Python2-style exception syntax is still used in django.utils.unittest 
(and
should be updated)
---+---
 Reporter:  garrison   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  py3k   | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by aaugustin):

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


Comment:

 The backport of unittest2 is only there for Python 2.6.

 I avoid modifying vendored library unless I absolutely need to.

 I wasn't aware it would trigger warnings during installation.

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

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